logind TakeDevice fails for Xen Virtual Keyboard #22944
Labels
Comments
|
Full strace: udevadm test output: |
|
my educated guess is that you don#t actually have a working seat, and that's the precondition for devices to be able to be taken. What does "loginctl seat-status seat0" say? |
poettering
added
the
needs-reporter-feedback ❓
|
Here is the output. Thank you for taking a look. |
|
hmm, interesting. but i think you are right, this has something to do with the fact that the parent input device is not matched somehow and thus doesn#t get a udev input device. That's something to look into. what does "udevadm info /sys/class/input/input6" say? i.e. on the parent input device? It needs to have the "seat" tag assigned, and I figure this is missing for you, probably because it is on such a weird bus. what happens if you do |
|
Here you go: |
yuwata
added
bug 🐛
|
Sorry for the late response. When you invoke Could you try to call If the above works, then next, please create the following .rules file: Then, reboot the system, and please provide the debugging logs of systemd-udevd for |
yuwata
added
the
needs-reporter-feedback ❓
|
Thanks for taking a look @yuwata . It's showing up as input9/event8 now (rawhide kernel 6.0-rc6). This is strange. Running the Also Here is the output from 00-debug-input.rules: |
|
Ah, so, no event for |
So, let me confirm, systemd-udev-trigger.service logs the similar message(s), right? |
|
Correct - there is no systemd-udev-trigger doesn't have anything interesting: On a fresh boot, there are no dmesg entries about failing to send the uevent. |
This sounds a kernel bug or limitation of Xen (or misconfigurarion in your Xen setup?) for me. The uevent file for input9 (/sys/devices/virtual/input/input9/uevent) is readable? If so, could you provide the contents and access mode ( |
|
BTW, a dirty workaround for the issue seems creating the following drop-in file with |
|
It's empty: Here are some of the other Xen virtual devices. udevadm trigger runs for them without error. The "Cannot allocate memory" made me remember this: https://lore.kernel.org/xen-devel/87o8dw52jc.fsf@vps.thesusis.net/T/ . It's a bug report with ENOMEM and uevents. May be unrelated, but ENOMEM and uevent seem similar. |
Seems this is exactly the same issue. The kernel log is about the failure of Could you show the result of |
Also, the gdm override seems make the Xen keyboard work. I am confused why manually running |
|
I'll pursue patching the xen_kbdfront driver to cut down on the list of keys. Thanks for your help, @yuwata |
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this issue
Oct 20, 2022
xen kbdfront registers itself as being able to deliver *any* key since it doesn't know what keys the backend may produce. Unfortunately, the generated modalias gets too large and uevent creation fails with -ENOMEM. This can lead to gdm not using the keyboard since there is no seat associated [1] and the debian installer crashing [2]. Trim the ranges of key capabilities by removing some BTN_* ranges. While doing this, some neighboring undefined ranges are removed to trim it further. This removes: BTN_DPAD_UP(0x220)..BTN_DPAD_RIGHT(0x223) Empty space 0x224..0x229 Emtpy space 0x2bd..0x2bf BTN_TRIGGER_HAPPY(0x2c0)..BTN_TRIGGER_HAPPY40(0x2e7) Empty space 0x2e8..0x2ff The modalias shrinks from 2082 to 1754 bytes. [1] systemd/systemd#22944 [2] https://lore.kernel.org/xen-devel/87o8dw52jc.fsf@vps.thesusis.net/T/ Cc: Phillip Susi <phill@thesusis.net> Cc: stable@vger.kernel.org Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
|
Kernel patch submitted upstream: https://lore.kernel.org/xen-devel/20221019201458.21803-1-jandryuk@gmail.com/ |
yuwata
added
not-our-bug
and removed
bug 🐛
|
@jandryuk Thank you for your work! Please let us know when your (or another) patch for the issue is merged to the kernel upstream. |
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this issue
Dec 9, 2022
xen kbdfront registers itself as being able to deliver *any* key since it doesn't know what keys the backend may produce. Unfortunately, the generated modalias gets too large and uevent creation fails with -ENOMEM. This can lead to gdm not using the keyboard since there is no seat associated [1] and the debian installer crashing [2]. Trim the ranges of key capabilities by removing some BTN_* ranges. While doing this, some neighboring undefined ranges are removed to trim it further. An upper limit of KEY_KBD_LCD_MENU5 is still too large. Use an upper limit of KEY_BRIGHTNESS_MENU. This removes: BTN_DPAD_UP(0x220)..BTN_DPAD_RIGHT(0x223) Empty space 0x224..0x229 Empty space 0x28a..0x28f KEY_MACRO1(0x290)..KEY_MACRO30(0x2ad) KEY_MACRO_RECORD_START 0x2b0 KEY_MACRO_RECORD_STOP 0x2b1 KEY_MACRO_PRESET_CYCLE 0x2b2 KEY_MACRO_PRESET1(0x2b3)..KEY_MACRO_PRESET3(0xb5) Empty space 0x2b6..0x2b7 KEY_KBD_LCD_MENU1(0x2b8)..KEY_KBD_LCD_MENU5(0x2bc) Empty space 0x2bd..0x2bf BTN_TRIGGER_HAPPY(0x2c0)..BTN_TRIGGER_HAPPY40(0x2e7) Empty space 0x2e8..0x2ff The modalias shrinks from 2082 to 1550 bytes. A chunk of keys need to be removed to allow the keyboard to be used. This may break some functionality, but the hope is these macro keys are uncommon and don't affect any users. [1] systemd/systemd#22944 [2] https://lore.kernel.org/xen-devel/87o8dw52jc.fsf@vps.thesusis.net/T/ Cc: Phillip Susi <phill@thesusis.net> Cc: stable@vger.kernel.org Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this issue
Oct 11, 2023
xen kbdfront registers itself as being able to deliver *any* key since it doesn't know what keys the backend may produce. Unfortunately, the generated modalias gets too large and uevent creation fails with -ENOMEM. This can lead to gdm not using the keyboard since there is no seat associated [1] and the debian installer crashing [2]. Trim the ranges of key capabilities by removing some BTN_* ranges. While doing this, some neighboring undefined ranges are removed to trim it further. An upper limit of KEY_KBD_LCD_MENU5 is still too large. Use an upper limit of KEY_BRIGHTNESS_MENU. This removes: BTN_DPAD_UP(0x220)..BTN_DPAD_RIGHT(0x223) Empty space 0x224..0x229 Empty space 0x28a..0x28f KEY_MACRO1(0x290)..KEY_MACRO30(0x2ad) KEY_MACRO_RECORD_START 0x2b0 KEY_MACRO_RECORD_STOP 0x2b1 KEY_MACRO_PRESET_CYCLE 0x2b2 KEY_MACRO_PRESET1(0x2b3)..KEY_MACRO_PRESET3(0xb5) Empty space 0x2b6..0x2b7 KEY_KBD_LCD_MENU1(0x2b8)..KEY_KBD_LCD_MENU5(0x2bc) Empty space 0x2bd..0x2bf BTN_TRIGGER_HAPPY(0x2c0)..BTN_TRIGGER_HAPPY40(0x2e7) Empty space 0x2e8..0x2ff The modalias shrinks from 2082 to 1550 bytes. A chunk of keys need to be removed to allow the keyboard to be used. This may break some functionality, but the hope is these macro keys are uncommon and don't affect any users. [1] systemd/systemd#22944 [2] https://lore.kernel.org/xen-devel/87o8dw52jc.fsf@vps.thesusis.net/T/ Cc: Phillip Susi <phill@thesusis.net> Cc: stable@vger.kernel.org Signed-off-by: Jason Andryuk <jandryuk@gmail.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
systemd version the issue has been seen with
Used distribution
Linux kernel version used (
uname -a)CPU architecture issue was seen on
Expected behaviour you didn't see
Apr 01 12:55:09 fedora gnome-shell[937]: Could not open device /dev/input/event5: GDBus.Error:System.Error.ENODEV: No such deviceThe "Xen Virtual Pointer" and "Xen Virtual Multi-touch" devices are "taken" properly. Only mouse (Xen Virtual Pointer) is actually transmitting input events though since the multi-touch backend is not connected. "Xen Virtual Keyboard" is sending input properly according to
libinput debug-events.Adding SYSTEMD_LOG_LEVEL=debug to logind does not add any useful information for why TakeDevice fails.
event5 has parent input6. strace on logind shows failure to read udev data before sending the ENODEV error:
There is data in the major:minor, /run/udev/data/c13:69, but not for the parent. The Xen Pointer has both major:minor and parent (input7) entries in /run/udev/data.
The strace failure seems to be session_device_verify calling manager_process_seat_device which returns from here
systemd/src/login/logind-core.c
Lines 286 to 288 in fb2fcad
That means the keyboard isn't registered so it returns ENODEV here
systemd/src/login/logind-session-device.c
Lines 304 to 307 in 947796e
The Xen Virtual Keyboard driver, xen-kbdfront, is unusual as it registers as being able to generate every input. Partially this is problematic as it is therefore detected as a joystick as seen in the
udevadm infooutput below.I tried hacking up the udev rules to prevent the joystick and uaccess labeling, but that was insufficient. TakeDevice still failed.
Any pointers appreciated.
Unexpected behaviour you saw
Steps to reproduce the problem
Additional program output to the terminal or log subsystem illustrating the issue
The text was updated successfully, but these errors were encountered: