Bug 97117

hmm, I wonder if the subdevice logic is broken here. Can you give me the evemu-describe output of this device (all of them if it has multiple event nodes)

Created attachment 125462 [details]
evemu-describe output for offending keyboard

The evemu-describe output for the keyboard that is causing this issue.

The keyboard is an Amazon Basics Bluetooth keyboard, Model #: KT-1081, ASIN: B005EOWBKE.

Can you reproduce it when the bt device is connected but you use a different keyboard to log in? Trying to figure out what exactly causes the issue here.

I just had this happen, so here are the steps.

I didn't touch the computer for about an hour, which means the BT
keyboard would have went to sleep. I came back to the computer and hit
the shift key on the BT keyboard a couple of times to wake the computer
up. I remembered this issue and logged in with the keyboard on the
laptop and, after logging in, had found that the X server had restarted.

I also locked the screen and immediately logged in with the laptop
keyboard while the BT keyboard is still connected and the X server did
not restart. So just having the device connected doesn't seem to be the
issue. The BT keyboard actually needs to be used while X is "sleeping"
with the login screen for lightdm showing.

Created attachment 125499 [details] [review]
0001-Block-input-events-while-creating-the-virtual-subdev.patch

Can you give this one a try please? the cause seems to be that the device sends events before the subdevice is fully initialized. I managed to reproduce this in gdb (mostly anyway) but I'm not sure I triggered the exact same race as you do.

https://patchwork.freedesktop.org/patch/103896/
https://patchwork.freedesktop.org/patch/103897/

Created attachment 125673 [details]
Xorg crash log after patch

Finally got around to test this but it's still a problem. It seems like my bluetooth keyboard is now ignored before I can log into lightdm, but X still crashes if I press a key on it to wake it up.

any chance you can attach gdb to it (from another machine) and get more of a backtrace?

otherwise, try addr2line to figure out which invocation of libinput_device_config_tap_get_finger_count we're crashing here. [1]
I can't quite figure out where the race is, it could be during set up or during input event reading.


[1] http://who-t.blogspot.com.au/2014/02/making-sense-of-backtraces-with.html

fwiw, I tested server 1.18.4 with xf86-input-libinput from git while running the libinput test suite. That one creates about 5000 devices in 5 minutes and triggers a lot of the race conditions we've seen during device startup (and highly likely yours is one of those). With 0168716fa I can finish the libinput test suite run without any crashes, suggesting that whatever you saw is probably fixed. If you can try xf86-input-libinput from git, that'd be great, thanks.

ping?

Created attachment 126677 [details]
Backtrace.

I am seeing what I suspect is the same crash that Joe is seeing. For me, it shows up if I switch to a virtual console, then attach a USB keyboard.

I am using libinput 1.5.0 and xf86-input-libinput from git (I first saw the crash on my main laptop, which has 0.19.0, so I tried updating after I found this bug, but it did not help.)

Backtrace attached. Let me know if there is anything else you'd like me to provide.

you'll need to try libinput from git, I don't have a release for these fixes yet

xf86-input-libinput from git, sorry, libinput itself doesn't matter

The trace that I attached was with xf86-input-libinput from git.

oh, whoops, sorry. I think I found the issue, not sure how quickly I'll get a patch out though. afaict the only way to reproduce this is when the parent device is disabled before the subdevice is added. not sure how exactly this is triggered though, but this seems like a design bug anyway.

(In reply to Mike Gorse from comment #11)
> I am seeing what I suspect is the same crash that Joe is seeing. For me, it
> shows up if I switch to a virtual console, then attach a USB keyboard.

do you vt-switch back with that keyboard, or what triggers the crash? I'm trying to reproduce this here but no combination I tried so far triggered the crash.

(In reply to Peter Hutterer from comment #16)
> (In reply to Mike Gorse from comment #11)
> > I am seeing what I suspect is the same crash that Joe is seeing. For me, it
> > shows up if I switch to a virtual console, then attach a USB keyboard.
> 
> do you vt-switch back with that keyboard, or what triggers the crash? I'm
> trying to reproduce this here but no combination I tried so far triggered
> the crash.

If I switch to a virtual console, then attach a USB keyboard, then X crashes. I'm not at a point where I could switch back to my original X session with the keyboard attached, since X is already gone.

can I have the evemu-describe of your keyboard? I wonder if there's some property that matters.

ping?

Ok, I have a reproducer, it crashes with this backtrace when a mixed keyboard/mouse device is added (e.g. the Logitech K400) and this server flags are present:

Section "ServerFlags"
  Option "AutoEnableDevices" "off"
EndSection

I doubt you have those locally, but somehow you trigger the same bug.

https://patchwork.freedesktop.org/patch/121494/

for the archives, the AED off simply serves to reproduce it with systemd-logind. I didn't originally reproduce it because of logind, the bug is reproducible without logind while VT-switched away (see the commit message too)


commit 72bac84df9ce72f2baf730655ecc23f1692d1e64
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue Nov 15 11:23:08 2016 +1000

    If the parent libinput_device is unavailable, create a new one

*** Bug 99390 has been marked as a duplicate of this bug. ***