On 28.08.23 10:53, José Ramón Muñoz Pekkarinen wrote: > On Sun, 27 Aug 2023 at 18:59, José Ramón Muñoz Pekkarinen > <koalinux@xxxxxxxxx> wrote: >>> >>> Excuse the long wait, I've been investigating with the kde community >>> and reading the code of libinput, systemd and the like, and I managed to >>> find a difference that I'm not quite sure it is relevant to narrow the issue. >>> While the keyboard is populated in the udev database as this: >>> >>> $ udevadm info -e >>> P: /devices/platform/i8042/serio0/input/input0 >>> M: input0 >>> R: 0 >>> U: input >>> E: DEVPATH=/devices/platform/i8042/serio0/input/input0 >>> E: SUBSYSTEM=input >>> E: PRODUCT=11/1/1/ab54 >>> E: NAME="AT Translated Set 2 keyboard" >>> E: PHYS="isa0060/serio0/input0" >>> E: PROP=0 >>> E: EV=120013 >>> E: KEY=402000000 3803078f800d001 feffffdfffefffff fffffffffffffffe >>> E: MSC=10 >>> E: LED=7 >>> E: MODALIAS=input:b0011v0001p0001eAB54-e0,1,4,11,14,k71,72,73,74,75,76,77,79,7A,7B,7C,7D,7E,7F,80,8C,8E,8F,9B,9C,9D,9E,9F,A3,A4,A5,A6,AC,AD,B7,B8,B9,D9,E2,ram4,l0,1,2,sfw >>> >>> There is no longer a corresponding entry under /run/udev/data, >>> the following is the output of the ls -la /run/udev/data on 6.4.12: >>> >>> total 116 >>> [...] >>> >>> To what I read, having it in the db either populated >>> by the file under /run/udev/data, or populated from sysfs >>> should be enough, but for some reason, it seems systemd >>> and libudev expects the file under this folder. > > I found that according to some early output on udev, the problem > maybe that Gentoo is triggering the device discovery before the > kernel is having multiple uevent files available. Retriggering the > device discovery on a later stage makes the discovery of the > devices work correctly and I can use the devices as in former > kernels. The command to do so is: > > # udevadm trigger --type=devices --action=add > > Is this something that can be improved from kernel end or should > I just look for some solution on Gentoo side to delay that trigger and > be done with it? So strictly speaking all this sounds a lot like this is caused by kernel regression that thus should be fixed in the kernel once this was bisected (which iirc hasn't happened yet). OTOH this afaics (please correct me if I'm wrong!) is the first such report, so the problem is likely pretty specific or might only occur on your system. In that case just looking for some solution for your system might be fine. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page.
