Xorg/xinput does not recognise evdev devices in Docker (Alpine base image) - docker

I'm trying to run an Xorg server in Docker, due to the host OS not having any X installed, nor can it preserve installed packages between updates (however, Docker containers are preserved).
My goal is to run an X app in "kiosk" mode (no desktop environment, no window manager, just a single X app taking up the whole display), confined to the Docker container - specifically, Chromium to open the web management interface of the host (which is embedded in the distro).
After reading a swathe of Xorg/Xinput articles, setup guides, manuals and whatnot, and I'm still not sure what's going wrong.
This is my current Dockerfile:
FROM alpine:3.16
# Install Xorg
RUN \
apk add --no-cache \
xorg-server eudev mesa \
xinput xinit xhost evtest \
xf86-input-libinput xf86-video-fbdev xf86-input-evdev \
dbus xrandr xset xsetroot \
xeyes libinput mesa-dri-swrast mesa-dri-gallium mesa-egl
# Install Chromium
RUN \
apk add --no-cache \
chromium
CMD [ "/usr/bin/xinit", "/usr/bin/chromium-browser", "--no-sandbox", "--kiosk" ]
Then run it by passing in all the necessary udev entries:
docker run --rm -it \
--device=/dev/input \
--device=/dev/console \
--device=/dev/dri \
--device=/dev/fb0 \
--device=/dev/tty \
--device=/dev/tty1 \
--device=/dev/vga_arbiter \
--device=/dev/snd \
--cap-add=SYS_TTY_CONFIG \
alpine-xorg:latest http://172.17.0.1:8123/
In my case, I'm trying to use a 7" touchscreen HDMI display, designed for Raspberry Pis (however, I'm not using a Pi, but an Intel based mini PC).
Xorg logs aren't much help, they contain just init information about Xinput, no devices identified or anything.
Here's the log: https://paste-bin.xyz/65152
I've also fiddled around with evtest - in my case, /dev/input/event3 corresponds to the touchscreen's input, and evtest successfully recognises them: https://paste-bin.xyz/65154
However xinput doesn't even see these as a possible device:
a369b238e0f1:/var/log# xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
According to the Xorg logs, the appropriate init scripts have been loaded:
[ 3724.820] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
/usr/share/X11/xorg.conf.d/10-evdev.conf exists, and contains all the needed entries:
#
# Catch-all evdev loader for udev-based systems
# We don't simply match on any device since that also adds accelerometers
# and other devices that we don't really want to use. The list below
# matches everything but joysticks.
Section "InputClass"
Identifier "evdev pointer catchall"
MatchIsPointer "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection
Section "InputClass"
Identifier "evdev keyboard catchall"
MatchIsKeyboard "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection
Section "InputClass"
Identifier "evdev touchpad catchall"
MatchIsTouchpad "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection
Section "InputClass"
Identifier "evdev tablet catchall"
MatchIsTablet "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection
Section "InputClass"
Identifier "evdev touchscreen catchall"
MatchIsTouchscreen "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection
Where is this setup going wrong, why can't xinput register the evdev devices when the necessary events are clearly there and usable?

Related

Is there a guide on porting edk2 to a new ARM64 platform?

I am new to EDK2.
For porting ekd2 firmware to a new ARM64 platform, it would be good to first get a minimum edk2 port which can run UEFI Shell at least, improvements can be added gradually based on that.
It seems that the first step is rather steep, e.g., how to determine a minimal set of "items" in .dsc and .fdf file for a platform? In my case, I would like to build the .fd for my platform and treat it as BL33 of TF-A, effectively I would like to build an edk2 firmware to replace u-boot.
It seems that such a guide is hard to find on the web. I found a old version of edk2 which contains some instructions, but apparently they are obsolete (not exist in latest master branch, while can be found in UDK branches such as UDK2014), and I am not sure why those documents are removed from master branch.
Currently I can build .fd for FVP (edk2-platforms/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc), and it seems that the build output FVP_AARCH64_EFI.fd is supposed to be treated as BL33. Theoretically this could be a prototype for my new ARM64 platform, but to me it's too complex to start with: the firmware is about 2.5MiB in size (as compare to 500K of u-boot), so I guess it's far from a "minimum" version. but it's hard to figure out what features to be removed (and how).
I am wondering if there is a detailed guide on such topic...
After 1 month of trial and error, today I managed to bring my ARM64 platform into a UEFI Shell environment. I treat it as my 1st milestone on the EDK2 journey. Below I will try to summarize the steps I took so far, as a tentative answer to my question above. Guidance/corrections/comments are welcomed.
Get familiar with UEFI/PI spec and EDK2 implementation by reading books/specs/articles. Well, UEFI/PI specs are thousands of pages long...how to start? My main reading list is:
"Beyond Bios--Developing with the Unified Extensible Firmware Interface", 3rd ed, by Vincent Zimmer, et al. As the authors explained, the book is a kind of high level summary of the thousands-paged specs. And I find that the book is well organized for a new comer to get familiar with various UEFI related concepts. The main purpose of the 1st read (before playing with edk2 code base) is to get familiar with concepts and architectural ideas, not the details yet. Related sections need to be consulted later when reading EDK2 implementations.
EDK2 specs, including:
EDKII User Manual
EDKII Build Specification
EDKII DSC/FDF/DEC/INF File Specification
Various articles on the web...
Get a reference platform which can correctly boot a FD image built from latest EDK2 source, and play with the boot manager and Shell environment a bit. In my case, I chose RPi4B. For me, this is very important, as the reference platform serves as a handrail during the whole process, that whenever I encounter bugs or have doubts, I check the source/log of the reference platform. This solves most of the problems I encountered. Btw, always generating "build log" and "build report" for both reference platform and the target platform, as the two files contains very detailed information for comparison and check. Consult the EDK2 build spec on how to generate these two files during build.
I use the following script to build for RPi4B platform:
#!/bin/bash
# https://github.com/tianocore/edk2-platforms#how-to-build-linux-environment
export WORKSPACE=/home/bruin/work/tianocore
export PACKAGES_PATH=$WORKSPACE/edk2:$WORKSPACE/edk2-platforms:$WORKSPACE/edk2-non-osi
pushd $WORKSPACE
rm -rf ./Build/RPi4
source edk2/edksetup.sh
echo "Building BaseTools..."
make -C edk2/BaseTools all
#sudo apt install acpica-tools # iasl
# pip install antlr4-python3-runtime # -Y EXECUTION_ORDER
echo "Building firmware for Pi4B..."
GCC5_AARCH64_PREFIX=aarch64-none-linux-gnu- build \
-n 4 \
-a AARCH64 \
-p Platform/RaspberryPi/RPi4/RPi4.dsc \
-t GCC5 \
-b NOOPT \
-v -d 9 -j RPi4-build.log \
-y RPi4-build-report.txt \
-Y PCD \
-Y LIBRARY \
-Y DEPEX \
-Y HASH \
-Y BUILD_FLAGS \
-Y FLASH \
-Y FIXED_ADDRESS \
-Y EXECUTION_ORDER \
all
How to use the build result RPI_EFI.fd on RPi4B, consult the following:
edk2-platforms/Platform/RaspberryPi/RPi4/Readme.md
readme.md inside https://github.com/pftf/RPi4/releases/download/v1.17/RPi4_UEFI_Firmware_v1.32.zip. btw, I need to replace the original start4.elf and fixup4.dat with the ones in the zip file, otherwise, the boot of RPi4 will fail, complaining something like below:
RpiFirmwareGetClockRate: Get Clock Rate return: ClockRate=0 ClockId=C
ASSERT [ArasanMMCHost] /home/bruin/work/tianocore/edk2-platforms/Platform/RaspberryPi/
Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c(263): BaseFrequency != 0
It's worth to analysis the RPI_EFI.fd content to some extend, by using some UEFI utilities. I mainly use the GUI version UEFITool of sudo apt install uefitool uefitool-cli. Other tools are also available. The anotomy of RPI_EFI.fd is of help when reading EDK2 build specs for checking understanding of the concepts.
One special aspect of RPI_EFI.fd is that the 1st 128K is bl31.bin binary from ATF. I guess this is due to the special booting connfiguration methods for RPi. For my platform, I don't need such kind of packaging, I only need to build the UEFI image MY.fd, which is treated as BL33 image and packaged into fip.bin togehter with BL2 and BL31 images by ATF build script.
Another aspect to notice is the "reset vector" in the begining of the .fd file. This related to the entry point of UEFI image (and entry point of each EDK2 modules), as well as interpreting the BL instruction for AArch64. Basically, it can be summarized as below:
The first [Components] in RPI_EFI.fd is ArmPlatformPkg/PrePi/PeiUniCore.inf, which is of MODULE_TYPE = SEC.
What's this component: this is the first (and only) SEC (Security) module in RPi4. What the name PrePi and Pei implies?
... the PI spec is not tied to edk2 PEIMs, and I don't see where EDKII PEI modules are currently the only "acknowledged" silicon init environment. The edk2 tree itself seems to contain platforms that don't use the edk2 PEI module set at all, but (IIRC) jump from SEC to DXE. I believe "ArmPlatformPkg/PrePi" and "ArmVirtPkg/PrePi" are related to this.
--- https://listman.redhat.com/archives/edk2-devel-archive/2020-November/msg00021.html
Its entry point: all UEFI components have the same entry point (_ModuleEntryPoint).
By "component", it means either a UEFI driver and UEFI app, both are PE32 executables, usually with suffix .efi.
The .efis are converted from ELF executables (.dll) by GenFw tool: modifying the file headers.
To verify that "all components' entry point is _ModuleEntryPoint":
Check the .dll generating command line in build report (build -y <BUILD_REPORT_FILE>), we have two flags "aarch64-none-linux-gnu-gcc" -o xxx.dll -u _ModuleEntryPoint -Wl,-e,_ModuleEntryPoint ...:
-u: gcc --help -v|grep "undefined SYMBOL" gives -u SYMBOL --undefined SYMBOL: star with undefined reference to SYMBOL.
Wl,-e: ld --help|grep "entry" gives -e ADDRESS, --entry ADDRESS Set start address.
Check all .dll files that Entry point address == _ModuleEntryPoint: find . -type f -name "*.dll" -exec sh -c "readelf -a {} |grep -E 'Entry point address|_ModuleEntryPoint'" \;
Its entry point is the entry point of whole UEFI FD image (i.e., from bl33_base_addr jump to this _ModuleEntryPoint):
Topology of the UEFI Firmware File
A UEFI Firmware File (actually a UEFI Firmware Device - FD file) is a collection of UEFI binaries encapsulated into a single image. The format of this image is defined by the Platform Initialization Specification Volume 3. A Vector Table is located at the base of this file. A 'BL' branch instruction at the base of the firwmare (location of the Reset Entry into the Vector Table) will jump to the first 'SEC' module of the UEFI Firmware Image.
--- https://github.com/lzeng14/tianocore/wiki/ArmPkg-Debugging
To verify the statements above:
Disassember the reset vector (i.e., the 1st word) of generated .FD (we got offset=0x360):
$ xxd -l 4 -e TEST.fd <== dump 4 bytes in little endian
00000000: 140000d8 <== BL {PC}+(0xd8<<2); offset=0x360
Check the Entry point in .dll (we got offset=0x240):
$ aarch64-none-elf-objdump -t ArmPlatformPrePiUniCore.dll|grep _ModuleEntryPoint
0000000000000240 g F .text 0000000000000000 _ModuleEntryPoint
$ readelf -h ArmPlatformPrePiUniCore.dll|grep Entry
Entry point address: 0x240
Compare contents of two files at different offset (we got identicial content):
$ xxd -s 0x360 -l 64 TEST.fd <== skip 0x360 bytes, dump 64 bytes
00000360: 901e 0094 050a 0094 ea03 00aa a1cd 0a58 ...............X
00000370: 0200 e0d2 2200 c0f2 0240 a0f2 0200 80f2 ...."....#......
00000380: c303 a0d2 e3ff 9ff2 6304 00d1 6300 028b ........c...c...
00000390: 0400 a1d2 0400 80f2 2000 03eb 8400 0054 ........ ......T
$ xxd -s 0x240 -l 64 ArmPlatformPrePiUniCore.dll <== skip 0x240 bytes
00000240: 901e 0094 050a 0094 ea03 00aa a1cd 0a58 ...............X
00000250: 0200 e0d2 2200 c0f2 0240 a0f2 0200 80f2 ...."....#......
00000260: c303 a0d2 e3ff 9ff2 6304 00d1 6300 028b ........c...c...
00000270: 0400 a1d2 0400 80f2 2000 03eb 8400 0054 ........ ......T
Prepare an empty pkg, and make it build ok. The main purpuse is to do some exercise with EDK2 build system, and use the empty pkg as the start point for the new platform.
Make a copy of RaspberryPi.dec, change all gRaspberry to gMyPlatform.
Make a copy of RPi4.dsc and RPi4.fdf, and comment out all stuff in DSC and FDF file.
Replace all GUIDs in DSC/FDF/DEC files, generating new ones using online guid generator.
Note that PCD are declared in DEC files, and DEC files are refered by modules (INF files). As the empty package contains no module, no PCD definition will be available in FDF. So for a success build of the empty package, we need to comment out all PCD reference in FDF.
The NOOPT build command for MyPlatform is as below:
#!/bin/bash
export WORKSPACE=/home/bruin/work/tianocore
export PACKAGES_PATH=$WORKSPACE/edk2:$WORKSPACE/edk2-platforms:$WORKSPACE/edk2-non-osi
pushd $WORKSPACE
source edk2/edksetup.sh
echo "Building BaseTools..."
make -C edk2/BaseTools all
echo "Building UEFI firmware for MyPlatform..."
GCC5_AARCH64_PREFIX=aarch64-none-linux-gnu- build \
-n 4 \
-a AARCH64 \
-p Platform/MyCorp/MyPlatform/MyPlatform.dsc \
-t GCC5 \
-b NOOPT \
-v -d 9 -j MyPlatform-build.log \
-y MyPlatform-build-report.txt \
-Y EXECUTION_ORDER \
-Y PCD \
-Y LIBRARY \
-Y DEPEX \
-Y HASH \
-Y BUILD_FLAGS \
-Y FLASH \
-Y FIXED_ADDRESS \
all
popd
Add the 1st component ArmPlatformPrePiUniCore. This component is to prepare the HOBs for DXE phae. The main purpose is to get serial port working and memory config correct. Another purpose of this step is to familiar with steps for adding a component/module/lib. Below is a brief summary of the steps:
Uncomment the module's INF into both DSC ([Components] section), and FDF ([FV.FVMAIN_COMPACT]).
Rebuild the pkg, and resolve all Instance of library class [xxxLib] is not found errors reported, by updating [LibraryClasses] sections of DSC.
This step is a repeating process for dozens of times.
Some lib-class has multiple lib-instances, making sure choose the appropriate lib-instance (ref the build-report of RPi4).
if encounter ModuleEntryPoint.iiii:31: Error: immediate out of range: enable gArmTokenSpaceGuid.PcdFdBaseAddress and gArmTokenSpaceGuid.PcdFdSize in FDF.
if encounter undefined reference to _gPcd_BinaryPatch_PcdSerialClockRate: set PcdSerialClockRate in [PcdsPatchableInModule] section in DSC. FIXME: why? ref.
Check the PCDs listed in build log: inspect any abnormal PCD values, and supply correct values.
Customize platform-specific drivers or libraries.
SerialPortLib: locate the lib-class header file (MdePkg/Include/Library/SerialPortLib.h) by find edk2 -type f -name "*.dec" -exec grep -Hn SerialPortLib. The following functions are required:
SerialPortInitialize()
SerialPortWrite()
SerialPortRead()
SerialPortPoll()
SerialPortSetControl(): RETURN_UNSUPPORTED
SerialPortGetControl(): RETURN_UNSUPPORTED
SerialPortSetAttributes(): RETURN_UNSUPPORTED
ArmPlatformLib: interface header at Include/Library/ArmPlatformLib.h. The following functions are required:
ArmPlatformGetCorePosition(): return cpu idx in the cluster given the MPIDR value. this function is used in _ModuleEntryPoint for setting stack for secondary cores. Assuming one cluster for now.
ArmPlatformIsPrimaryCore()
ArmPlatformGetPrimaryCoreMpId()
ArmPlatformGetBootMode()
ArmPlatformPeiBootAction()
ArmPlatformInitialize()
ArmPlatformGetVirtualMemoryMap()
ArmPlatformGetPlatformPpiList()
etc...
Uncomment more modules in DSC/FDF, module by module...For driver/libs which are RPi platform specific, we can:
either search the edk2/edk2-platform for similiar driver or lib instances, or
copy the RPi4 implementation and comment out most of the content, make the pkg build success first, and then bug fixing.
Debugging: my current main debugging method is through adding "printf()", i.e., the edk2 macro DEBUG((DEBUG_INFO,)). One needs to set gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel to an appropriate value to see more debug info.

Buildroot - RPI3 - Find the BCM43438 firmware to enable wireless

i'm a beginner.
i use a RPI3 and a buildroot build system and try to enable wireless.
I followed several links without success.
In particulary, i followed this link : https://delog.wordpress.com/2014/10/10/wireless-on-raspberry-pi-with-buildroot/
and verify my linux kernel wireless options are activated, but no results.
However, the options i used on the buildroot . config file seems to be good :
debian-host:/build/buildroot# egrep -i "wireless|wpa|80211" .config
# BR2_PACKAGE_WIRELESS_REGDB is not set
BR2_PACKAGE_WIRELESS_TOOLS=y
BR2_PACKAGE_WIRELESS_TOOLS_LIB=y
BR2_PACKAGE_WPA_SUPPLICANT=y
BR2_PACKAGE_WPA_SUPPLICANT_NL80211=y
BR2_PACKAGE_WPA_SUPPLICANT_AP_SUPPORT=y
BR2_PACKAGE_WPA_SUPPLICANT_WIFI_DISPLAY=y
# BR2_PACKAGE_WPA_SUPPLICANT_MESH_NETWORKING is not set
BR2_PACKAGE_WPA_SUPPLICANT_AUTOSCAN=y
BR2_PACKAGE_WPA_SUPPLICANT_EAP=y
BR2_PACKAGE_WPA_SUPPLICANT_HOTSPOT=y
BR2_PACKAGE_WPA_SUPPLICANT_DEBUG_SYSLOG=y
BR2_PACKAGE_WPA_SUPPLICANT_WPS=y
BR2_PACKAGE_WPA_SUPPLICANT_CLI=y
BR2_PACKAGE_WPA_SUPPLICANT_WPA_CLIENT_SO=y
BR2_PACKAGE_WPA_SUPPLICANT_PASSPHRASE=y
# BR2_PACKAGE_WPA_SUPPLICANT_DBUS_OLD is not set
# BR2_PACKAGE_WPA_SUPPLICANT_DBUS_NEW is not set
BR2_PACKAGE_WPAN_TOOLS=y
I installed a minibian an another rpi3, i noticed a firmware was used and i installed it by a :
apt-get install firmware-brcm80211
If the firmware is not installed, I noticed that iwlist wlan0 scan have empty results. On my RPI3-buildroot-system, after booting, lsmod show no modules.
I need to load manually by modprobe or by /etc/modules. So i load the same modules used on minibian, so i did (i loaded bluetooth mods also)
uname -a
Linux pi3 4.9.13-rt12-v7 #1 SMP Mon Mar 20 14:04:21 CET 2017 armv7l GNU/Linux
pwd
/lib/modules/4.9.13-rt12-v7/kernel/drivers
find . -name "*brcm*.ko"
./net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko
./net/wireless/broadcom/brcm80211/brcmutil/brcmutil.ko
modprobe 8192cu
modprobe brcmfmac
modprobe brcmutil
modprobe hci_uart
modprobe bnep
and the lsmod show :
lsmod
Module Size Used by Not tainted
8192cu 581125 0
hci_uart 19956 0
btbcm 7992 1 hci_uart
bnep 12051 0
bluetooth 364941 3 hci_uart,btbcm,bnep
brcmfmac 222136 0
brcmutil 9156 1 brcmfmac
cfg80211 543530 1 brcmfmac
rfkill 20944 2 bluetooth,cfg80211
ipv6 405794 18 [permanent]
but
iwlist wlan0 scan
wlan0 Interface doesn't support scanning.
I don't arrive to have the same result as my minibian distro with my apt-get ..
What is the way to retrieve the buildroot process to have the same result that on my minibian ?
I've forget something ?
Thanks for helping me.
When using make menuconfig, enable rpi-wifi-firmware under Target packages > Hardware handling > Firmware to include the firmware files.
For WiFi on the Raspberry Pi, you need to enable the following packages in your defconfig file :
BR2_PACKAGE_WPA_SUPPLICANT=y
BR2_PACKAGE_RPI_WIFI_FIRMWARE=y
If you want to reference any other things, I have an older buildroot external tree here for the Raspberry Pi.

Will my AirPrint Code connect to an IPv6-only Printer?

Below is my code to connect to an IPv4 Printer. Everything is OK.
NSString *printerURL = #"ipp://192.168.1.3:631/ipp/print" //IPv4 : OK
UIPrinter *myPrint = [UIPrinter printerWithURL:[NSURL URLWithString:printerURL]];
[myPrint contactPrinter:^(BOOL available) {
if(!available){
// Show error
}
[printInteraction printToPrinter:myPrint completionHandler:^(UIPrintInteractionController * _Nonnull printInteractionController, BOOL completed, NSError * _Nullable error) {
// Print
}];
}];
Because I do not have the IpV6 printer, I do not know what will happen with the code below:
NSString *printerURL = #"ipp://FE80::FE3F:DBFF:FE51:6BA:631/ipp/print" //IPv6 : ????
Will it connect to an IPv6 printer?
I don't have an IPv6 printer neither, nor an AirPrint-capable device.
But I have a suggestion for you, how you could test if your code works for IPv6 connections:
Use a MacBook to fake an environment which makes a iOS device in your LAN/WLAN think that they "see" and can connect to an AirPrint device.
Here are the detailed steps:
Make sure an IPv6 address is assigned to your MacBook. (How you do that is beyond the scope of this answer.)
Make sure that your MacBook's CUPS services is allowing only IPv6 connections by adding a line to cupsd.conf:
Listen [xxxx::xxxx:xxxx:xxxx:xxxx]:631
Listen /private/var/run/cupsd
# Port 631
Make sure that your cupsd.conf has also this line:
DefaultAuthType None
This makes sure you'll not need to debug Authentication or Authorization problems on top of your IPv6 and AirPrint functionality. (You can change that back later, once your current problem is solved.)
Create a shared print queue on your MacBook and name it, say, abcd. The queue does not need to connect to an AirPrint device -- any other printer will be "good enough". Also, the printer can also be IPv4-only, or USB, or Bluetooth -- as long as your MacBook can connect to it. (How you do that is beyond the scope of this answer.)
Test your printer: make sure your MacBook prints to it, and make sure that other clients are able to print to the shared queue.
Your Mac clients will now be able to "see" and use your abcd print queue -- but your iOS clients will not (yet) see an AirPrint device.
Now use the dns-sd utility to announce a fake AirPrint device to your local network, pointing to the real print queue named abcd. The general syntax for the command is this:
dns-sd -P <Name> <Type> <Domain> <Port> <Hostname> <IP> [<TXT>...]
Now to run the real command, open a Terminal.app window and type this:
dns-sd \
-P AirPrint-abcd \
_ipp._tcp,_universal \
local. \
631 \
mymacbook.local. \
xxxx::xxxx:xxxx:xxxx:xxxx \
pdl="application/pdf,image/urf" \
kind="document" \
priority="1" \
product="Model Name of my Printer" \
rp="printers/abcd" \
URF="DM3" \
Duplex="T" \
Color="T" \
note="Testing AirPrint on MacBook" \
txtvers="1" \
qtotal="1" \
printer-type="0x0480FFFC" \
printer-state="3" \
air="none" \
UUID="54321abc-1234-1234-abcd-ffa8e4bdcbf8"
Here,
xxxx::xxxx:xxxx:xxxx:xxxx is the IPv6 address of your MacBook
mymacbook is the hostname of your MacBook
Now your iOS client should be able to see and use an AirPrint device named AirPrint-abcd. The service announcement also tells them that the connection path to this AirPrinter is the IPv6 address of your MacBook and the port to use is 631.
Additional Explanation:
The -P parameter to the dns-sd utility will make a Bonjour "proxy announcement" to your local LAN/WLAN. For details about this utility see man dns-sd. For more background, see dns-sd.org and these other answers.

Running Erlang on Xeon Phi

How can I compile the VM and run Erlang programs on the Intel Xeon Phi coprocessor?
Intel Xeon Phi is not a typical x86_64 architecture, therefore it's not possible to run the official Erlang VM on it. The only way to do it is to use cross-compilation and build the VM yourself on a different (host) machine where Erlang is supported, so that it runs on a target system (Phi in this case).
Xeon Phi also supports slightly different instruction set than a typical x86_64 architecture, so you also need to edit the code. If you just cross-compile the VM without touching the code, you will probably get an error:
/tmp/iccvaLP3vas_.s: Assembler messages:
/tmp/iccvaLP3vas_.s:25794: Error: `mfence' is not supported on `k1om'
So first of all you need to add #ifndef clauses around memory fence instructions, which are not supported on Phi (mfence, lfence and sfence). This boils down to opening the erts/include/internal/i386/ethr_membar.h file and adding following preprocessor directives:
#ifndef __MIC__
...
#endif
around __asm__ statements in funtions ethr_mfence__, ethr_sfence__ and ethr_lfence__ e.g.
static __inline__ void
ethr_mfence__(void)
{
#if ETHR_SIZEOF_PTR == 4
if (ETHR_X86_RUNTIME_CONF_HAVE_NO_SSE2__)
ETHR_NO_SSE2_MEMORY_BARRIER__;
else
#endif
#ifndef __MIC__
__asm__ __volatile__ ("mfence\n\t" : : : "memory");
#endif
}
Now you can try to cross-compile it. First download the sources (in my case Erlang VM 17.5), then run:
$ cd otp_src_17.5
$ export ERL_TOP=`pwd`;
$ ./configure \
--host=k1om-unknown-linux-gnu \
--build=x86_64-pc-linux-gnu \
--without-termcap \
--without-javac \
--without-ssl \
--prefix=/path/to/my/new_installation \
CC=icc \
CFLAGS=-mmic \
LDFLAGS=-mmic \
DED_LD=icc \
DED_LDFLAGS="-mmic -shared -Wl,-Bsymbolic" \
DED_LD_FLAG_RUNTIME_LIBRARY_PATH="-Wl,-R"
$ make
$ make install
icc is the official Intel Compiler and -mmic flag is required for compiling for Xeon Phi. The host and build flags are the systems/architectures of respectively the machine where you compile and the machine which you compile for (Phi). In my case they had following values, but if it's different for you, you might want to use the config.guess script which automatically detects your OS/CPU architecture.
$ ./config.guess
$ x86_64-pc-linux-gnu
And that's it! Now you should be able to ssh on your Phi and run Erlang.
$ ssh my-phi-coprocessor
$ cd /path/to/my/new_installation/
$ export PATH=`pwd`/bin:$PATH;
$ erl -version
Erlang (SMP,ASYNC_THREADS) (BEAM) emulator version 6.4

vagrant provisioning switches character encoding

I was running vagrant provision today and it failed with the following error:
Package configuration┌──────────────────────────┤ Configuring grub-pc ├──────────────────────────┐│││
The GRUB boot loader was previously installed to a disk that is no
││ longer present, or whose unique identifier has changed for some reason.
││ It is important to make sure that the installed GRUB core image stays in
││ sync with GRUB modules and grub.cfg. Please check again to make sure
││ that GRUB is written to the appropriate boot devices.
││││ If you're unsure which drive is designated as boot drive by your BIOS,
││ it is often a good idea to install GRUB to all of them.
││││ Note: it is possible to install GRUB to partition boot records as well,
││ and some appropriate partitions are offered here. However, this forces
││ GRUB to use the blocklist mechanism, which makes it less reliable, and
││ therefore is not recommended.
││││<Ok>│││└───────────────────────────────────────────────────────────────────────────┘
But then, to my surprise, it started printing a stack trace in a very strange encoding...
STDERR: F▒␋┌␊␍ ├⎺ ⎺⎻␊┼ ├␊⎼└␋┼▒┌.␍␊␉␌⎺┼°: ┬␤␋⎻├▒␋┌ ⎺┤├⎻┤├ ├␤␊ ▒␉⎺┴␊ ␊⎼⎼⎺⎼⎽, ±␋┴␋┼± ┤⎻!
␍⎻┐±: ␊⎼⎼⎺⎼ ⎻⎼⎺␌␊⎽⎽␋┼± ±⎼┤␉-⎻␌ (--␌⎺┼°␋±┤⎼␊):
⎽┤␉⎻⎼⎺␌␊⎽⎽ ␋┼⎽├▒┌┌␊␍ ⎻⎺⎽├-␋┼⎽├▒┌┌▒├␋⎺┼ ⎽␌⎼␋⎻├ ⎼␊├┤⎼┼␊␍ ␊⎼⎼⎺⎼ ␊│␋├ ⎽├▒├┤⎽ 255
E⎼⎼⎺⎼⎽ ┬␊⎼␊ ␊┼␌⎺┤┼├␊⎼␊␍ ┬␤␋┌␊ ⎻⎼⎺␌␊⎽⎽␋┼±:
±⎼┤␉-⎻␌
E: S┤␉-⎻⎼⎺␌␊⎽⎽ /┤⎽⎼/␉␋┼/␍⎻┐± ⎼␊├┤⎼┼␊␍ ▒┼ ␊⎼⎼⎺⎼ ␌⎺␍␊ (1)
---- E┼␍ ⎺┤├⎻┤├ ⎺° ▒⎻├-±␊├ ┤⎻±⎼▒␍␊ -≤ ----
R▒┼ ▒⎻├-±␊├ ┤⎻±⎼▒␍␊ -≤ ⎼␊├┤⎼┼␊␍ 100
R␊⎽⎺┤⎼␌␊ D␊␌┌▒⎼▒├␋⎺┼:
---------------------
# I┼ /┴▒⎼/␌␤␊°/␌▒␌␤␊/␌⎺⎺┐␉⎺⎺┐⎽/␌⎺└└⎺┼-⎽⎺°├┬▒⎼␊/⎼␊␌␋⎻␊⎽/␍␊°▒┤┌├.⎼␉
49: ␊│␊␌┤├␊ "▒⎻├-±␊├-┤⎻±⎼▒␍␊-≤" ␍⎺
50: ␌⎺└└▒┼␍ "▒⎻├-±␊├ ┤⎻±⎼▒␍␊ -≤"
51: ␊┼␍
C⎺└⎻␋┌␊␍ R␊⎽⎺┤⎼␌␊:
------------------
# D␊␌┌▒⎼␊␍ ␋┼ /┴▒⎼/␌␤␊°/␌▒␌␤␊/␌⎺⎺┐␉⎺⎺┐⎽/␌⎺└└⎺┼-⎽⎺°├┬▒⎼␊/⎼␊␌␋⎻␊⎽/␍␊°▒┤┌├.⎼␉:49:␋┼ ◆°⎼⎺└_°␋┌␊'
␊│␊␌┤├␊("▒⎻├-±␊├-┤⎻±⎼▒␍␊-≤") ␍⎺
⎼␊├┤⎼┼⎽ 0
␌⎺└└▒┼␍ "▒⎻├-±␊├ ┤⎻±⎼▒␍␊ -≤"
▒␌├␋⎺┼ "⎼┤┼"
⎼␊␌␋⎻␊_┼▒└␊ "␍␊°▒┤┌├"
⎼␊├⎼≤_␍␊┌▒≤ 2
␌⎺⎺┐␉⎺⎺┐_┼▒└␊ "␌⎺└└⎺┼-⎽⎺°├┬▒⎼␊"
␉▒␌┐┤⎻ 5
⎼␊├⎼␋␊⎽ 0
␊┼␍
And the terminal prompt returned...in that same encoding! All my input was converted to that encoding (capital letters appeared as usual though).
My question is: why does Vagrant change the encoding of my terminal window, and does it have something to do with the GRUB error?
I'm on a Macbook Pro.
If you are using apt-get upgrade/dist-upgrade, try it:
sudo DEBIAN_FRONTEND=noninteractive apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" upgrade
I wrote a function for it. Just copy paste it into your provision script:
function aptget {
# to prevent encoding problem
sudo DEBIAN_FRONTEND=noninteractive apt-get -y \
-o Dpkg::Options::="--force-confdef" \
-o Dpkg::Options::="--force-confold" \
$#
}
aptget update
aptget upgrade
Note: I had posted this as a comment to #gustavohenrique's answer but it didn't had a good format as a comment. So, I've posted this as an answer although it's a duplicate answer. It's more of a supplement. Sorry for the disruption.

Resources