Control: reassign -1 systemd 251-2 On 2022-05-25 20:43:50 +0200, Yves-Alexis Perez wrote: > I've quickly tried here and didn't have any issue, but if it's > hardware- dependent it's likely the reason why neither Michael nor > me have been able to reproduce (whether gdm3 or lightdm).
I'm reassigning the bug to systemd because after getting annoyed too many times, I decided to install xdm, and I exactly have the same issue with it. I can't try with gdm3 unfortunately because it is uninstallable due to a buggy strong dependency chain. Anyway: > I'm not sure it's actually linked to the display manager That's also what I think, and this would explain why both lightdm and xdm are affected. > (rather than systemd itself, Note that the problem appeared just after the upgrade to systemd 251-2, and while there was never any issue before, it is now 100% reproducible after a reboot (but not just after a reboot). It seems that after the systemd upgrade, the display manager is started several seconds earlier, which may be related to this problem. > or maybe something in the X stack), but maybe it might help if you > could test with another DM (gdm3 or another one) just in case? See above. I've also compared the result with my laptop, where I do not have this issue, and I can see a difference in the systemd-logind logs: * On my laptop (no issues): Jun 23 04:29:33 zira systemd-logind[846]: Watching system buttons on /dev/input/event9 (Power Button) Jun 23 04:29:33 zira systemd-logind[846]: Watching system buttons on /dev/input/event8 (Lid Switch) Jun 23 04:29:33 zira systemd-logind[846]: Watching system buttons on /dev/input/event7 (Sleep Button) Jun 23 04:29:33 zira systemd-logind[846]: Watching system buttons on /dev/input/event3 (Apple, Inc Apple Keyboard) Jun 23 04:29:33 zira systemd-logind[846]: Watching system buttons on /dev/input/event0 (AT Translated Set 2 keyboard) Jun 23 04:29:33 zira systemd-logind[846]: Watching system buttons on /dev/input/event11 (HP WMI hotkeys) only 1 second after the boot. * On my desktop machine, which has the issue: Jun 24 14:12:02 cventin systemd-logind[607]: Watching system buttons on /dev/input/event0 (Power Button) Jun 24 14:12:02 cventin systemd-logind[607]: Watching system buttons on /dev/input/event1 (Power Button) Jun 24 14:12:03 cventin systemd-logind[607]: Watching system buttons on /dev/input/event2 (DELL Dell USB Entry Keyboard) 9 seconds after the boot. However, this much larger delay doesn't explain this issue, as shown by an excerpt of the history on this machine: 2018-11-16 4.18.0-2-amd64 systemd 239 2 seconds 2019-01-03 4.18.0-3-amd64 systemd 240 2 seconds 2019-02-19 4.19.0-3-amd64 systemd 240 1 second 2019-02-22 4.19.0-3-amd64 systemd 241 2 seconds 2019-05-09 4.19.0-5-amd64 systemd 241 1 second 2019-05-27 4.19.0-5-amd64 systemd 241 2 seconds 2019-06-19 4.19.0-5-amd64 systemd 241 3 seconds 2019-07-19 4.19.0-5-amd64 systemd 241 3 seconds 2019-08-07 4.19.0-5-amd64 systemd 241 3 seconds 2019-08-19 5.2.0-2-amd64 systemd 241 5 seconds 2019-08-21 5.2.0-2-amd64 systemd 241 5 seconds 2019-08-22 5.2.0-2-amd64 systemd 242 6 seconds 2019-08-30 5.2.0-2-amd64 systemd 242 4 seconds 2019-09-06 5.2.0-2-amd64 systemd 242 5 seconds 2019-09-23 5.2.0-2-amd64 systemd 242 5 seconds 2019-09-30 5.2.0-3-amd64 systemd 242 5 seconds 2019-10-11 5.2.0-3-amd64 systemd 242 5 seconds 2019-10-21 5.3.0-1-amd64 systemd 242 7 seconds 2019-11-04 5.3.0-1-amd64 systemd 242 7 seconds 2019-11-12 5.3.0-2-amd64 systemd 243-5 8 seconds 2019-11-13 5.3.0-2-amd64 systemd 243-5 12 seconds 2019-11-15 5.3.0-2-amd64 systemd 243-6 11 seconds 2019-11-18 5.3.0-2-amd64 systemd 243-7 11 seconds 2019-11-20 5.3.0-2-amd64 systemd 243-8 11 seconds 2019-12-02 5.3.0-2-amd64 systemd 243-9 11 seconds 2019-12-03 5.3.0-2-amd64 systemd 244-3 12 seconds 2019-12-09 5.3.0-3-amd64 systemd 244-3 12 seconds 2020-01-06 5.4.0-1-amd64 systemd 244-3 13 seconds 2020-01-07 5.4.0-2-amd64 systemd 244-3 10 seconds 2020-01-21 5.4.0-3-amd64 systemd 244-3 12 seconds 2020-01-28 5.4.0-3-amd64 systemd 244.1-1 11 seconds 2020-02-10 5.4.0-3-amd64 systemd 244.2-1 11 seconds 2020-02-18 5.4.0-4-amd64 systemd 244.3-1 12 seconds 2020-03-13 5.4.0-4-amd64 systemd 245-2 11 seconds 2020-07-01 5.4.0-4-amd64 systemd 245.6-1 12 seconds 2020-07-17 5.7.0-1-amd64 systemd 245.6-3 11 seconds 2020-08-17 5.7.0-1-amd64 systemd 246.1-1 10 seconds 2020-08-21 5.7.0-1-amd64 systemd 246.2-1 10 seconds 2020-09-08 5.7.0-3-amd64 systemd 246.4-1 12 seconds 2020-09-21 5.8.0-2-amd64 systemd 246.5-1 10 seconds 2020-09-22 5.8.0-2-amd64 systemd 246.6-1 10 seconds 2020-10-13 5.8.0-3-amd64 systemd 246.6-1 12 seconds 2020-10-28 5.9.0-1-amd64 systemd 246.6-2 12 seconds 2020-10-26 5.9.0-3-amd64 systemd 246.6-5 11 seconds 2021-01-06 5.10.0-1-amd64 systemd 247.1-3 10 seconds 2021-01-07 5.10.0-1-amd64 systemd 247.2-4 10 seconds 2021-06-01 5.10.0-7-amd64 systemd 247.3-5 10 seconds 2021-07-22 5.10.0-8-amd64 systemd 247.3-6 10 seconds 2021-08-16 5.10.0-8-amd64 systemd 247.9-1 10 seconds 2021-09-22 5.14.0-1-amd64 systemd 247.9-1 9 seconds 2021-09-29 5.14.0-1-amd64 systemd 247.9-3 10 seconds 2021-10-04 5.14.0-1-amd64 systemd 247.9-4 10 seconds 2021-10-06 5.14.0-2-amd64 systemd 247.9-4 10 seconds 2021-10-20 5.14.0-2-amd64 systemd 249.5-1 11 seconds 2021-11-09 5.14.0-4-amd64 systemd 249.5-2 11 seconds 2021-11-23 5.15.0-1-amd64 systemd 249.7-1 10 seconds 2022-01-12 5.15.0-2-amd64 systemd 250.2-1 9 seconds 2022-01-18 5.15.0-2-amd64 systemd 250.2-3 8 seconds 2022-01-21 5.15.0-3-amd64 systemd 250.3-1 9 seconds 2022-02-09 5.16.0-1-amd64 systemd 250.3-2 9 seconds 2022-03-17 5.16.0-5-amd64 systemd 250.4-1 8 seconds 2022-05-05 5.17.0-1-amd64 systemd 250.4-1 8 seconds 2022-05-13 5.17.0-2-amd64 systemd 250.4-1 8 seconds 2022-05-16 5.17.0-2-amd64 systemd 250.4-1 8 seconds 2022-05-24 5.17.0-2-amd64 systemd 251-2 10 seconds 2022-06-07 5.17.0-2-amd64 systemd 251-2 9 seconds 2022-06-13 5.17.0-3-amd64 systemd 251.2-5 10 seconds 2022-06-20 5.17.0-3-amd64 systemd 251.2-5 10 seconds 2022-06-23 5.18.0-2-amd64 systemd 251.2-5 10 seconds I recall that the issue suddenly started to occur after the upgrade to systemd 251-2. > I don't think there's really code in the display manager to specifically > handle keyboards, I'd assume it's in the X part, but I might be wrong. The issue could also be in the X server, e.g. in case of a race condition whose effects appeared after the upgrade to systemd 251-2. There are log messages related to the keyboard in /var/log/Xorg.0.log, but timestamps are relative to some unknown point. So I can't compare with the systemd logs. This is really silly! > And it might be possible that the DM is starting “too soon” on your box, but > delaying likely won't fix the keyboard delay itself, it's just that the UI > will be available later (maybe it's better for consistency though). This would be a poor workaround to the real issue. There are absolutely no reasons why the keyboard wouldn't work earlier (it is working without any issue in grub). -- Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
