libinput version: 1.5.1 libinput 1.5.1-1.fc25.x86_64 My Thinkpad Yoga S1 has a weird race condition on bootup affecting input drivers - maybe 3 out of every 5 boots, the system boots with no working mouse and/or keyboard. I just reboot again and it works fine, although sometimes it takes several boots to get both working. This happened since I got the laptop and loaded it with F23... I upgraded to F25 + Wayland today and was able to reproduce the issue. The following are input settings for all devices on the system when it is in the state where upon boot the keyboard worked but the pointer did not: ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ xwayland-touch:13 id=7 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ xwayland-keyboard:13 id=6 [slave keyboard (3)] Device 'Virtual core pointer': Device Enabled (119): 1 Coordinate Transformation Matrix (121): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 Device 'Virtual core XTEST pointer': Device Enabled (119): 1 Coordinate Transformation Matrix (121): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 XTEST Device (238): 1 Device 'xwayland-touch:13': Device Enabled (119): 1 Coordinate Transformation Matrix (121): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 Device Accel Profile (242): 0 Device Accel Constant Deceleration (243): 1.000000 Device Accel Adaptive Deceleration (244): 1.000000 Device Accel Velocity Scaling (245): 10.000000 Device 'Virtual core keyboard': Device Enabled (119): 1 Coordinate Transformation Matrix (121): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 Device 'Virtual core XTEST keyboard': Device Enabled (119): 1 Coordinate Transformation Matrix (121): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 XTEST Device (238): 1 Device 'xwayland-keyboard:13': Device Enabled (119): 1 Coordinate Transformation Matrix (121): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 I couldn't run evemu on the pointer because there wasn't a deviec for it if I understand correctly, just for the touchscreen. If I reboot the system so the mouse works again, and run xinput list, i get a pointer and relative-pointer device that wasn't there before: RL: http://paste.fedoraproject.org/493306/14804435/ ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ xwayland-pointer:13 id=6 [slave pointer (2)] ⎜ ↳ xwayland-relative-pointer:13 id=7 [slave pointer (2)] ⎜ ↳ xwayland-touch:13 id=9 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ xwayland-keyboard:13 id=8 [slave keyboard (3)]
fwiw, xinput list from within wayland doesn't provide us with much info, all you get is the xwayland emulated devices. something is going wrong here, can you attach the journalctl -b -k output here please. I guess this means you can't get past the login screen? What happens if you boot into a tty, does it work then?
ping? is this still an issue?
Hi Peter, it is still an issue (updated f25, kernel-4.9.7-201.fc25.x86_64 <= altho this is super crash-happy, it happens on that one but I'm mostly using kernel-4.8.8-300.fc25.x86_64) Sorry for not following up. I got stuck because when I was reproducing it the keyboard wasn't working either so I couldn't run journalctl and didn't have a second computer. Sometimes the keyboard does work and if that's the case I can type my password into the login screen and then can't do anything. Let me trying booting into tty and see if I can reproduce.
Booted into tty using kernel-4.8.8-300.fc25.x86_64 (put '3' on the grub kernel line) and got to the tty and keyboard did not work. So I can reproduce the issue booting into tty.
ok, I'm gonna punt you to benjamin because this looks like it's a kernel bug. A dmesg would be good from such a bootup where it doesn't work (journalctl -k -b <negative boot number>, where the number is -1 for the last boot, etc)
Okay cool. I'm attaching the log, I found it from when this originally happened. I tried to reproduce just now by rebooting about 10 times and could not but I did find the log where it happened.
Created attachment 129801 [details] Log from when the keyboard was non functional in runlevel 3
Sorry for the delay, I was on PTO enjoying time off :) It looks from the logs that the PS/2 nodes are simply ignored, so I guess the controller just bails out. Just to be sure, could you also attach a dmesg when both keyboard and touchpad are working? If they are still handled by PS/2, then there will be some trial and error to do with some kernel module parameters (i8042.noloop, i8042.nomux, i8042.noselftest, i8042.reset, i8042.notimeout and maybe i8042.kbdreset) - Just dumping them here so that I don't need to refetch them later.
Created attachment 130003 [details] dmesg output from when keyboard and trackpoint are working Here you go Benjamin! This is the dmesg output from when the keyboard and trackpoint are working.
Thanks for the logs. So you are using a PS/2 keyboard, and a PS/2 mouse, so we will need to check the flags I was mentioning in my previous comment. I think those that have the best chance of being useful are i8042.notimeout and i8042.nomux. So please append those 2 flags to the kernel boot line in grub ("i8042.notimeout=1 i8042.nomux=1"), and try to boot, and reboot, and reboot :) If these 2 flags reliably make both the touchpad and keyboard work, we will need to check which one is the right one (so please do the same tests with only one flag). Note: there might be an other slightly less tedious option which would consist in providing a dmesg of a failed keyboard/touchpad boot with i8042.debug=1. -> In that case make sure to test the keyboard before typing a password (cause the length can be detected from the number of key events, but the keys are masked). So please beware in such situation to not type the LUKS password or your password with the embedded keyboard.
Máirín, we're still waiting on data from you, see comment 10. Ttry with a newer kernel too, that's always useful ;)
ping?
Hi, I found this thread by searching the ACPI Exception/Error message, that i get as the first output during boot up and i actually found in the attached log by Máirín Duffy. I am using Debian 9.1 (stretch) on a ThinkPad Yoga (Type 20C0) with the following kernel version: Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64 If i remember correctly, with the former Debian Jessie, it did not show up. So far I did not discovered any problems. If i can help with further details to solve that issue, please let me know.
Hi Peter, Sorry to go AWOL; I tried newer kernels in F25 and no luck, but once I upgraded to F26 I haven't been able to reproduce the issue. However, I have new input issues with F26 :( trackpoint / synaptics loses sync by 2 bytes it seems every 10-15 minutes, and I lose control of the buttons; discovered switching VTs fixes it, but it seems one problem traded for another. Is it useful to file a bug on that? I brought the hardware in for Lyude to look at today.
After a debugging session with Máirín last week: adding psmouse.synaptics_intertouch=0 to the kernel command line seems to help with the issue. So I'm closing this bug for now, we know a workaround/the issue and can fix this in the kernel now.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.