Hi,
On Debian GNU/Hurd 0.9 (xserver-xorg-core 2:21.1.11-1,
hurd 1:0.9.git20230520-7, gnumach 1.8+git20230410-1), native Xorg
cannot start. It walks through dummy-driver init, GLX / DRISWRAST
init, all 23 extension inits, mouse input init, then dies in
kbd_drv.so with:
[295.288] (EE) Cannot set event mode on keyboard (Bad file descriptor)
kbd_drv.so issues a Linux-style "set event mode" ioctl against
/dev/cons/kbd (a /hurd/chrdev 156 33685736 translator), and the
chrdev returns EBADF because the gnumach console translator does
not implement the ioctl.
The natural fallbacks evdev and libinput are not packaged for
hurd-amd64:
/usr/lib/xorg/modules/input/
inputtest_drv.so
kbd_drv.so
mouse_drv.so
synaptics_drv.so
apt-cache search '^xserver-xorg-input'
xserver-xorg-input-{all,kbd,mouse,synaptics,elographics,mutouch}
(no -evdev or -libinput binary packages on hurd-amd64)
/dev/input/ not present
/dev/cons/kbd /hurd/chrdev 156 33685736
/dev/cons/mouse /hurd/chrdev 156 33685736
That is exactly why no evdev_drv.so ships: evdev's entire model is
read() of struct input_event records out of /dev/input/eventN, and
that surface does not exist on Hurd. Keyboard and mouse instead
surface through gnumach's console translator under /dev/cons/.
User impact: no native X session on real hardware. Xvfb works as a
headless workaround (emacs-lucid + EXWM attaches to it cleanly), but
there is no hardware-attached display path.
Packaging ask, two options, lower-effort first:
Option 1: shim translator that exposes /dev/input/event0 on top of
/dev/cons/kbd and /dev/input/event1 on top of /dev/cons/mouse,
marshalling chrdev events into struct input_event records on each
read(). evdev itself stays unchanged. Add hurd-amd64 to the
Architecture list in debian/control for xserver-xorg-input-evdev.
--- debian/control (xserver-xorg-input-evdev)
+++ debian/control (xserver-xorg-input-evdev)
@@
-Architecture: linux-any kfreebsd-any
+Architecture: linux-any kfreebsd-any hurd-amd64
Option 2: in-driver __GNU__ codepath in evdev itself that talks
/dev/cons/* directly and does scancode-to-keysym translation
in-driver. More work, fewer translators. Would also need upstream
buy-in on [email protected].
libinput is a strict superset of evdev (multi-touch, gestures);
evdev alone is enough to unblock the hardware-attached X story for
the first cut.
The gnumach console-translator side of the same issue (teach
/dev/cons/* the KDGKBMODE / KDSKBMODE ioctl family so kbd_drv.so
works unmodified) is filed in parallel on [email protected] (subject
"[gnumach] /dev/cons/kbd rejects kbd_drv.so set-event-mode ioctl
with EBADF; please implement KDSKBMODE or expose /dev/input/event*")
so the two threads stay linked.
Reproduction (canonical Debian GNU/Hurd 0.9, native QEMU console):
1. Boot canonical image to a text console.
2. apt install xserver-xorg-core xserver-xorg-input-kbd
xserver-xorg-input-mouse xinit
3. Write a one-line xorg.conf with Driver "dummy" for the screen
and the default keyboard / mouse stanzas.
4. startx 2>&1 | tee /tmp/xorg.log
5. observe the log ends with
"Fatal server error: Cannot set event mode on keyboard
(Bad file descriptor)" after the "Adding extended input device
<default keyboard>" line.
6. ls /usr/lib/xorg/modules/input/
-> exactly inputtest_drv.so kbd_drv.so mouse_drv.so synaptics_drv.so
7. ls /dev/input/ -> ENOENT.
Happy to test a shim translator or a hurd-amd64 evdev build once
either lands.
Filing channel alternative: salsa MR against
salsa.debian.org/xorg-team/driver/xserver-xorg-input-evdev once the
shim translator exists and the upstream evdev change (if needed) is
nailed down.
Thanks,
Borja Tarraso
[email protected]
