Very early on the boot of my system, when runit services start, I initialise libuinput virtual keyboard devices, that are clones of real devices, yet eudev fails to identify them consistently.
On real hardware the identification faliure occur stochastically, while on regular qemu vm it occurs always.
I have a void linux x86_64 glibc system where I installed the hkd hotkey demon as a runit service.
This hotkey software clones the devices given to it using libuinput, and passes the non-hotkey matching keyboard input through the clone.
I detected this bug via the usage of hkd as a service.
If I launch hkd on a steady system, eudev identifies the clone device properly and tags it with the appropriate properties / attributes like ID_INPUT=1, ID_INPUT_KEY=1, ID_INPUT_KEYBOARD=1.
However, if I have it launch at the time when standard runit services launch, this identification fails to happen consistently!
I experimented with various ways to delay the launch or force eudev to be in a consistent state in the run service file of my hkd deamon.
The first quasi-succesful solution was to put modprobe uniput; udevadm settle before exec-ing hkd. This worked flawlessly on the qemu vm, and my more modern laptop. However, on my old 2 core laptop the identification failed to occur, though rarely.
I also made a solution where I manually trigger an eudev rule that defines the ID_INPUT_KEYBOARD=1 property to the keyboard target devices. Interestingly the manual triggering forced eudev into a consistent state the qemu vm, and the virtual clone devices got all the proper attributes / properties.
My third succesful experiment was to run udevadm test-builtin input_id on the target keyboard devices, and this too forced eudev into a consistent state seemingly on the qemu vm.
I do not know if the latter two perfectly eliminated the problem on my old laptop or just made it highly improbable though.
Very early on the boot of my system, when runit services start, I initialise libuinput virtual keyboard devices, that are clones of real devices, yet eudev fails to identify them consistently.
On real hardware the identification faliure occur stochastically, while on regular qemu vm it occurs always.
I have a void linux x86_64 glibc system where I installed the hkd hotkey demon as a runit service.
This hotkey software clones the devices given to it using libuinput, and passes the non-hotkey matching keyboard input through the clone.
I detected this bug via the usage of hkd as a service.
If I launch hkd on a steady system, eudev identifies the clone device properly and tags it with the appropriate properties / attributes like ID_INPUT=1, ID_INPUT_KEY=1, ID_INPUT_KEYBOARD=1.
However, if I have it launch at the time when standard runit services launch, this identification fails to happen consistently!
I experimented with various ways to delay the launch or force eudev to be in a consistent state in the
runservice file of my hkd deamon.The first quasi-succesful solution was to put
modprobe uniput; udevadm settlebefore exec-ing hkd. This worked flawlessly on the qemu vm, and my more modern laptop. However, on my old 2 core laptop the identification failed to occur, though rarely.I also made a solution where I manually trigger an eudev rule that defines the ID_INPUT_KEYBOARD=1 property to the keyboard target devices. Interestingly the manual triggering forced eudev into a consistent state the qemu vm, and the virtual clone devices got all the proper attributes / properties.
My third succesful experiment was to run
udevadm test-builtin input_idon the target keyboard devices, and this too forced eudev into a consistent state seemingly on the qemu vm.I do not know if the latter two perfectly eliminated the problem on my old laptop or just made it highly improbable though.