Bug#1011523: systemd-logind: lightdm ignores keyboard input for the first 3 seconds

2024-05-27 Thread Luca Boccassi 
Control: close -1

On Fri, 15 Jul 2022 14:30:30 +0200 Michael Biebl 
wrote:
> Am 15.07.22 um 05:18 schrieb Vincent Lefevre:
> > Control: forwarded -1
https://github.com/systemd/systemd/issues/24026
> > 
> > On 2022-07-05 00:30:14 +0200, Michael Biebl wrote:
> >> Since this appears to be a regression in v251, please file this
> >> upstream at https://github.com/systemd/systemd/issues
> > 
> > OK, I've just reported the issue upstream.
> > 
> 
> Thanks, appreciated.

This is tracked upstream, there are no patches nor configuration
downstream, closing.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1011523: systemd-logind: lightdm ignores keyboard input for the first 3 seconds

2022-07-15 Thread Michael Biebl 

Am 15.07.22 um 05:18 schrieb Vincent Lefevre:

Control: forwarded -1 https://github.com/systemd/systemd/issues/24026

On 2022-07-05 00:30:14 +0200, Michael Biebl wrote:

Since this appears to be a regression in v251, please file this
upstream at https://github.com/systemd/systemd/issues


OK, I've just reported the issue upstream.



Thanks, appreciated.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011523: systemd-logind: lightdm ignores keyboard input for the first 3 seconds

2022-07-14 Thread Vincent Lefevre 
Control: forwarded -1 https://github.com/systemd/systemd/issues/24026

On 2022-07-05 00:30:14 +0200, Michael Biebl wrote:
> Since this appears to be a regression in v251, please file this
> upstream at https://github.com/systemd/systemd/issues

OK, I've just reported the issue upstream.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1011523: systemd-logind: lightdm ignores keyboard input for the first 3 seconds

2022-07-04 Thread Michael Biebl 
Since this appears to be a regression in v251, please file this upstream 
at https://github.com/systemd/systemd/issues


Thanks


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011523: systemd-logind: lightdm ignores keyboard input for the first 3 seconds

2022-06-29 Thread Vincent Lefevre 
On 2022-06-27 16:11:33 +0200, Vincent Lefevre wrote:
> cventin:~> systemd-analyze blame
> 10.812s NetworkManager-wait-online.service
[...]
> but the machine has 12 cores and I don't see a relation with
> systemd-logind.

Masking NetworkManager-wait-online.service doesn't solve the issue.

On 2022-06-27 15:39:51 +0200, Vincent Lefevre wrote:
> I'm wondering whether it could be related to this change:
> 
> Changes in udev:
> [...]
> * udevadm trigger gained a new --prioritized-subsystem= option to
>   process certain subsystems (and all their parent devices) earlier.
> 
>   systemd-udev-trigger.service now uses this new option to trigger
>   block and TPM devices first, hopefully making the boot a bit faster.
> 
> Also, I have plymouth installed on this machine. I should probably
> try without it to see if this makes a difference.

Uninstalling plymouth makes the boot faster, and in particular,
the display manager starts earlier, and I need to wait even more
before I can use the keyboard (there is still this 10-second
delay that appears in the logs).

However, reverting the change in systemd-udev-trigger.service by adding
/etc/systemd/system/systemd-udev-trigger.service with older contents
(from Debian/stable) as follows

--- /lib/systemd/system/systemd-udev-trigger.service2022-06-02 
20:07:11.0 +0200
+++ /etc/systemd/system/systemd-udev-trigger.service2022-06-29 
15:30:37.203967091 +0200
@@ -19,4 +19,5 @@
 [Service]
 Type=oneshot
 RemainAfterExit=yes
-ExecStart=-udevadm trigger --type=all --action=add 
--prioritized-subsystem=block,tpmrm
+ExecStart=udevadm trigger --type=subsystems --action=add
+ExecStart=udevadm trigger --type=devices --action=add

restores the old behavior. But I can see a 6-second freeze, e.g. on 2 tests:

Jun 29 15:36:57 cventin systemd[1]: Started Network Time Synchronization.
Jun 29 15:36:57 cventin systemd[1]: Reached target System Time Set.
Jun 29 15:37:03 cventin kernel: sr 2:0:0:0: Attached scsi generic sg0 type 5
Jun 29 15:37:03 cventin kernel: sr 3:0:0:0: Attached scsi generic sg1 type 5
Jun 29 15:37:03 cventin kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0

and

Jun 29 15:38:02 cventin systemd[1]: Started Network Time Synchronization.
Jun 29 15:38:02 cventin systemd[1]: Reached target System Time Set.
Jun 29 15:38:08 cventin kernel: sr 2:0:0:0: Attached scsi generic sg0 type 5
Jun 29 15:38:08 cventin kernel: sr 3:0:0:0: Attached scsi generic sg1 type 5
Jun 29 15:38:08 cventin kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0

Note that these "Attached scsi generic" messages occur only 1 second
after the boot without the change in systemd-udev-trigger.service, so
I'm wondering about the cause.

So it is possible that the new --prioritized-subsystem=block,tpmrm
option in systemd-udev-trigger.service introduced a side effect that
"fixes" the freeze (or was there a good reason for this freeze?) and
made an old keyboard issue appear, while it was previously hidden by
the freeze.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1011523: systemd-logind: lightdm ignores keyboard input for the first 3 seconds

2022-06-27 Thread Vincent Lefevre 
On 2022-06-27 15:39:51 +0200, Vincent Lefevre wrote:
[...]
> but systemd-logind logged about the keyboard 10 seconds after the
> boot, thus 5 seconds *after* the display manager was started:
> 
> Jun 24 17:21:26 cventin systemd-logind[606]: Watching system buttons on 
> /dev/input/event2 (DELL Dell USB Entry Keyboard)
> 
> So, what happens with systemd-logind there?

Just in case:

cventin:~> systemd-analyze blame
10.812s NetworkManager-wait-online.service
 2.341s loadcpufreq.service
 1.298s nvidia-persistenced.service
 1.204s gpm.service
  716ms accounts-daemon.service
  669ms avahi-daemon.service
  607ms cups.service
  565ms dev-sda5.device
  519ms atd.service
  516ms atopacct.service
  445ms systemd-journal-flush.service
  441ms lightdm.service
  431ms e2scrub_reap.service
  430ms lm-sensors.service
  399ms polkit.service
  392ms cpufrequtils.service
  362ms systemd-modules-load.service
  352ms mcelog.service
  346ms rtkit-daemon.service
  342ms udisks2.service
  341ms atop.service
  325ms dbus.service
  322ms ModemManager.service
  320ms systemd-udev-trigger.service
  291ms systemd-logind.service
  276ms exim4.service
  249ms apparmor.service
  192ms user@118.service
  179ms user@1000.service
  168ms rsyslog.service
  153ms systemd-journald.service
  150ms ssh.service
  140ms systemd-udevd.service
  137ms apache2.service
  134ms colord.service
  125ms apache-htcacheclean.service
  117ms lvm2-monitor.service
  106ms NetworkManager.service
  103ms keyboard-setup.service
[...]

but the machine has 12 cores and I don't see a relation with
systemd-logind.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1011523: systemd-logind: lightdm ignores keyboard input for the first 3 seconds

2022-06-27 Thread Vincent Lefevre 
On 2022-06-27 13:27:23 +0200, Michael Biebl wrote:
> What I can see here is that "Before" the Xorg server was apparently ready
> after 16.597/16.818 and "After" it is after 15.909/14.644. So it is actually
> quicker?

Yes, the X server is started earlier (because the display manager is
started earlier, I assume).

> So is this maybe just a perceived slowness?

But this does not explain why the keyboard isn't available immediately
by the X server like on my laptop. The systemd-logind logs show the
same kind of delay.

For instance, on my laptop, a fraction of second after the boot:

Jun 23 04:29:32 zira kernel: usb 2-6.2: New USB device found, idVendor=05ac, 
idProduct=0221, bcdDevice= 0.69
Jun 23 04:29:32 zira kernel: usb 2-6.2: New USB device strings: Mfr=1, 
Product=2, SerialNumber=0
Jun 23 04:29:32 zira kernel: usb 2-6.2: Product: Apple Keyboard
Jun 23 04:29:32 zira kernel: usb 2-6.2: Manufacturer: Apple, Inc
Jun 23 04:29:32 zira kernel: input: Apple, Inc Apple Keyboard as 
/devices/pci:00/:00:14.0/usb2/2-6/2-6.2/2-6.2:1.0/0003:05AC:0221.0001/input/input9
Jun 23 04:29:32 zira kernel: apple 0003:05AC:0221.0001: input,hidraw0: USB HID 
v1.11 Keyboard [Apple, Inc Apple Keyboard] on usb-:00:14.0-6.2/input0
Jun 23 04:29:32 zira kernel: apple 0003:05AC:0221.0002: Fn key not found (Apple 
Wireless Keyboard clone?), disabling Fn key handling
Jun 23 04:29:32 zira kernel: input: Apple, Inc Apple Keyboard as 
/devices/pci:00/:00:14.0/usb2/2-6/2-6.2/2-6.2:1.1/0003:05AC:0221.0002/input/input10
Jun 23 04:29:32 zira kernel: apple 0003:05AC:0221.0002: input,hidraw1: USB HID 
v1.11 Device [Apple, Inc Apple Keyboard] on usb-:00:14.0-6.2/input1

5 seconds later, about the display manager:

Jun 23 04:29:37 zira lightdm[3347]: pam_unix(lightdm-greeter:session): session 
opened for user lightdm(uid=116) by (uid=0)
Jun 23 04:29:37 zira systemd-logind[846]: New session c1 of user lightdm.
Jun 23 04:29:37 zira systemd[3381]: pam_unix(systemd-user:session): session 
opened for user lightdm(uid=116) by (uid=0)
Jun 23 04:29:37 zira systemd[1]: Started Session c1 of User lightdm.

but systemd-logind logged about the keyboard just 1 second after the
boot (thus before lightdm):

Jun 23 04:29:33 zira systemd-logind[846]: Watching system buttons on 
/dev/input/event3 (Apple, Inc Apple Keyboard)

So everything is fine there.

But on my desktop machine, a fraction of second after the boot:

Jun 24 17:21:16 cventin kernel: usb 2-14: New USB device found, idVendor=413c, 
idProduct=2107, bcdDevice= 1.04
Jun 24 17:21:16 cventin kernel: usb 2-14: New USB device strings: Mfr=1, 
Product=2, SerialNumber=0
Jun 24 17:21:16 cventin kernel: usb 2-14: Product: Dell USB Entry Keyboard
Jun 24 17:21:16 cventin kernel: usb 2-14: Manufacturer: DELL
Jun 24 17:21:16 cventin kernel: input: DELL Dell USB Entry Keyboard as 
/devices/pci:00/:00:14.0/usb2/2-14/2-14:1.0/0003:413C:2107.0001/input/input2
Jun 24 17:21:16 cventin kernel: hid-generic 0003:413C:2107.0001: input,hidraw0: 
USB HID v1.11 Keyboard [DELL Dell USB Entry Keyboard] on 
usb-:00:14.0-14/input0

5 seconds later, about the display manager:

Jun 24 17:21:21 cventin lightdm[827]: pam_unix(lightdm-greeter:session): 
session opened for user lightdm(uid=118) by (uid=0)
Jun 24 17:21:21 cventin systemd[831]: pam_unix(systemd-user:session): session 
opened for user lightdm(uid=118) by (uid=0)
Jun 24 17:21:21 cventin systemd[1]: Started Session c1 of User lightdm.

but systemd-logind logged about the keyboard 10 seconds after the
boot, thus 5 seconds *after* the display manager was started:

Jun 24 17:21:26 cventin systemd-logind[606]: Watching system buttons on 
/dev/input/event2 (DELL Dell USB Entry Keyboard)

So, what happens with systemd-logind there?

Perhaps that's actually the real issue (which didn't exist in
early 2019 and gradually became more and more apparent with the
maximum reached in November 2019). And the change in systemd 251
just revealed it.

But there might also be something wrong in the dependencies of
the services.

> That said, as neither Yves-Alexis nor me is able to reproduce any issues
> here, your best bet, if you think this is related to systemd, is to run a
> git bisect to find the commit which changed the behaviour.

I'm wondering whether it could be related to this change:

Changes in udev:
[...]
* udevadm trigger gained a new --prioritized-subsystem= option to
  process certain subsystems (and all their parent devices) earlier.

  systemd-udev-trigger.service now uses this new option to trigger
  block and TPM devices first, hopefully making the boot a bit faster.

Also, I have plymouth installed on this machine. I should probably
try without it to see if this makes a difference.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1011523: systemd-logind: lightdm ignores keyboard input for the first 3 seconds

2022-06-27 Thread Michael Biebl 

Am 24.06.22 um 16:39 schrieb Vincent Lefevre:

On 2022-06-24 15:57:22 +0200, Vincent Lefevre wrote:

On 2022-05-25 20:43:50 +0200, Yves-Alexis Perez wrote:

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.


Well, the X server is not the cause. As said in the Xorg logs:
The server relies on udev to provide the list of input devices.

And the logs show that before the upgrade to systemd 251, the delay
was less than 2 seconds, while after the upgrade to systemd 251,
the delay is now 4 - 7 seconds.

Before:

[14.784]
X.Org X Server 1.21.1.3
[16.597] (II) config/udev: Adding input device DELL Dell USB Entry Keyboard 
(/dev/input/event2)

[15.005]
X.Org X Server 1.21.1.3
[16.818] (II) config/udev: Adding input device DELL Dell USB Entry Keyboard 
(/dev/input/event2)

After:

[11.999]
X.Org X Server 1.21.1.3
[15.909] (II) config/udev: Adding input device DELL Dell USB Entry Keyboard 
(/dev/input/event2)

[ 7.688]
X.Org X Server 1.21.1.3
[14.644] (II) config/udev: Adding input device DELL Dell USB Entry Keyboard 
(/dev/input/event2)

Is the kernel stressed because systemd now starts too many services
in parallel?



What I can see here is that "Before" the Xorg server was apparently 
ready after 16.597/16.818 and "After" it is after 15.909/14.644. So it 
is actually quicker?

So is this maybe just a perceived slowness?

That said, as neither Yves-Alexis nor me is able to reproduce any issues 
here, your best bet, if you think this is related to systemd, is to run 
a git bisect to find the commit which changed the behaviour.


Regards,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011523: systemd-logind: lightdm ignores keyboard input for the first 3 seconds

2022-06-24 Thread Vincent Lefevre 
On 2022-06-24 15:57:22 +0200, Vincent Lefevre wrote:
> On 2022-05-25 20:43:50 +0200, Yves-Alexis Perez wrote:
> > 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.

Well, the X server is not the cause. As said in the Xorg logs:
The server relies on udev to provide the list of input devices.

And the logs show that before the upgrade to systemd 251, the delay
was less than 2 seconds, while after the upgrade to systemd 251,
the delay is now 4 - 7 seconds.

Before:

[14.784] 
X.Org X Server 1.21.1.3
[16.597] (II) config/udev: Adding input device DELL Dell USB Entry Keyboard 
(/dev/input/event2)

[15.005] 
X.Org X Server 1.21.1.3
[16.818] (II) config/udev: Adding input device DELL Dell USB Entry Keyboard 
(/dev/input/event2)

After:

[11.999] 
X.Org X Server 1.21.1.3
[15.909] (II) config/udev: Adding input device DELL Dell USB Entry Keyboard 
(/dev/input/event2)

[ 7.688] 
X.Org X Server 1.21.1.3
[14.644] (II) config/udev: Adding input device DELL Dell USB Entry Keyboard 
(/dev/input/event2)

Is the kernel stressed because systemd now starts too many services
in parallel?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1011523: systemd-logind: lightdm ignores keyboard input for the first 3 seconds

2022-06-24 Thread Vincent Lefevre 
Control: retitle -1 systemd-logind: display manager (lightdm, xdm) ignores 
keyboard input for the first 3 seconds on some hardware with systemd 251
Control: found -1 251.2-5

since I get the same issue with xdm and, only on one of my machines.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1011523: systemd-logind: lightdm ignores keyboard input for the first 3 seconds

2022-06-24 Thread Vincent Lefevre 
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-512 seconds
2019-11-15  5.3.0-2-amd64   systemd 243-611 seconds
2019-11-18  5.3.0-2-amd64   systemd 243-711 seconds
2019-11-20  5.3.0-2-amd64   systemd 243-811 seconds
2019-12-02  5.3.0-2-amd64   systemd 243-911 seconds
2019-12-03  5.3.0-2-amd64   systemd 244-312 seconds
2019-12-09  5.3.0-3-amd64   systemd 244-312 seconds
2020-01-06  5.4.0-1-amd64   systemd 244-313 seconds
2020-01-07  5.4.0-2-amd64   systemd 244-310 seconds
2020-01-21  5.4.0-3-amd64   systemd 244-312 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-211 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

Bug#1011523: systemd-logind: lightdm ignores keyboard input for the first 3 seconds

2022-05-25 Thread Yves-Alexis Perez 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2022-05-25 at 16:02 +0200, Michael Biebl wrote:
> Am 25.05.2022 um 15:35 schrieb Vincent Lefevre:
> > So, if I understand correctly, systemd now starts the user login
> > management very early, possibly before the hardware is ready. If
> > this is regarded as correct, does this mean that lightdm should
> > have code to detect when a keyboard is ready?
> > 
> 
> I have no idea what you mean here.
> Anyway, no need to CC me personally and let the lightdm maintainers deal 
> with it.
> 
Hi Michael, Vincent,

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 not sure it's actually linked to the display manager (rather than systemd
itself, 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?

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.

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).

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmKOeOYACgkQ3rYcyPpX
RFt/JwgAtrFpDNeEbESmyfsz/kRUhLXFcbHb0IWzPC7m/0nsP/lZRBdbWUZiMSAd
sowzOMZExA0rGtd1GJSjhxKLaELm9W1J8julh3zetskyZyPTR9gRB6bcNGYt00I7
0RsRXhSVdFF2g4cb3SyD4hdGGxzBeCtR4z2b1TyJRwVVt0RcqRUxPjquvCLeTnQa
B1lJ8g/X0Gdi8iJ4Yysu41tFd6SehvRC3gSxZT2m/l6L4xF5FJfOwVfhIJyDis4G
bnCJUEhK+5o66UrD3IKqmt3L+WnB0QrhaTb/ax8Qlq3OJlrMADzVnixFtHB6Vc0j
CJia4JCG+0k1EUDrqXqxjUdXW3kUGQ==
=Mc0a
-END PGP SIGNATURE-

Bug#1011523: systemd-logind: lightdm ignores keyboard input for the first 3 seconds

2022-05-25 Thread Michael Biebl 

Am 25.05.2022 um 15:35 schrieb Vincent Lefevre:

So, if I understand correctly, systemd now starts the user login
management very early, possibly before the hardware is ready. If
this is regarded as correct, does this mean that lightdm should
have code to detect when a keyboard is ready?



I have no idea what you mean here.
Anyway, no need to CC me personally and let the lightdm maintainers deal 
with it.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011523: systemd-logind: lightdm ignores keyboard input for the first 3 seconds

2022-05-25 Thread Vincent Lefevre 
On 2022-05-25 13:35:27 +0200, Michael Biebl wrote:
> I'm not really familiar with lightdm and I don't see any such issue
> with gdm3.

Well, this doesn't mean anything. I've just looked at what I obtain
on another machine (my laptop), which also now has systemd 251-2:

May 24 10:26:21 zira systemd[1]: Starting User Login Management...
May 24 10:26:22 zira systemd-logind[900]: New seat seat0.
May 24 10:26:22 zira systemd-logind[900]: Watching system buttons on 
/dev/input/event9 (Power Button)
May 24 10:26:22 zira systemd-logind[900]: Watching system buttons on 
/dev/input/event8 (Lid Switch)
May 24 10:26:22 zira systemd-logind[900]: Watching system buttons on 
/dev/input/event7 (Sleep Button)
May 24 10:26:22 zira systemd-logind[900]: Watching system buttons on 
/dev/input/event3 (Apple, Inc Apple Keyboard)
May 24 10:26:22 zira systemd-logind[900]: Watching system buttons on 
/dev/input/event0 (AT Translated Set 2 keyboard)
May 24 10:26:22 zira systemd-logind[900]: Watching system buttons on 
/dev/input/event11 (HP WMI hotkeys)
May 24 10:26:22 zira systemd[1]: Started User Login Management.
May 24 10:26:27 zira systemd-logind[900]: New session c1 of user lightdm.

So this seems to be hardware dependent. The issue seems to be that
the "Watching system buttons on" lines now occur much later than
expected on the other machine. Or actually, lightdm seems to start
much earlier:

With systemd 250.4-1:

May 24 14:12:15 cventin kernel: microcode: microcode updated early to revision 
0x49, date = 2021-08-11
[...]
May 24 14:12:23 cventin systemd[1]: Starting User Login Management...

i.e. an 8-second delay.

With systemd 251-2:

May 24 14:17:47 cventin kernel: microcode: microcode updated early to revision 
0x49, date = 2021-08-11
[...]
May 24 14:17:48 cventin systemd[1]: Starting User Login Management...

i.e. a 1-second delay.

> So I'm going to reassign this issue tentatively to lightdm, as its
> maintainer will probably be in a better positition to help you get proper
> debug logs from lightdm.

I had looked at lightdm logs, but couldn't find anything useful.

So, if I understand correctly, systemd now starts the user login
management very early, possibly before the hardware is ready. If
this is regarded as correct, does this mean that lightdm should
have code to detect when a keyboard is ready?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1011523: systemd-logind: lightdm ignores keyboard input for the first 3 seconds

2022-05-25 Thread Michael Biebl 

Control: reassign -1 lightdm

Am 24.05.22 um 14:40 schrieb Vincent Lefevre:

Package: systemd
Version: 251-2
Severity: minor

I'm using the lightdm display manager with lightdm-gtk-greeter.
After the systemd upgrade, for about the first 3 seconds after
the login box appears, keyboard input is ignored. Downgrading
systemd to 250.4-1 makes the problem disappear, and upgrading
it again makes the problem reappear.

The journalctl logs for systemd-logind

   journalctl -u systemd-logind.service -b [-1]

shows a time difference between these two systemd versions:

With systemd 250.4-1:

May 24 14:12:23 cventin systemd[1]: Starting User Login Management...
May 24 14:12:23 cventin systemd-logind[661]: New seat seat0.
May 24 14:12:23 cventin systemd[1]: Started User Login Management.
May 24 14:12:23 cventin systemd-logind[661]: Watching system buttons on 
/dev/input/event0 (Power Button)
May 24 14:12:23 cventin systemd-logind[661]: Watching system buttons on 
/dev/input/event1 (Power Button)
May 24 14:12:23 cventin systemd-logind[661]: Watching system buttons on 
/dev/input/event2 (DELL Dell USB Entry Keyboard)
May 24 14:12:27 cventin systemd-logind[661]: New session c1 of user lightdm.

With systemd 251-2:

May 24 14:17:48 cventin systemd[1]: Starting User Login Management...
May 24 14:17:48 cventin systemd-logind[603]: New seat seat0.
May 24 14:17:48 cventin systemd[1]: Started User Login Management.
May 24 14:17:52 cventin systemd-logind[603]: New session c1 of user lightdm.
May 24 14:17:57 cventin systemd-logind[603]: Watching system buttons on 
/dev/input/event0 (Power Button)
May 24 14:17:57 cventin systemd-logind[603]: Watching system buttons on 
/dev/input/event1 (Power Button)
May 24 14:17:57 cventin systemd-logind[603]: Watching system buttons on 
/dev/input/event2 (DELL Dell USB Entry Keyboard)

With systemd 250.4-1, I get "New session c1 of user lightdm" after the
"Watching system buttons on ..." messages, while with systemd 251-2,
I get it 5 seconds before, which could be related to this keyboard issue.

Note: of course, my keyboard is the "Dell USB Entry Keyboard" in question.


I'm not really familiar with lightdm and I don't see any such issue with 
gdm3.
So I'm going to reassign this issue tentatively to lightdm, as its 
maintainer will probably be in a better positition to help you get 
proper debug logs from lightdm.



@lightdm maintainers: if you find that this is a genuine bug in systemd, 
please re-assign back.


Michael