Hi all, I think there is some race conditions between the udev rules and the hwdb and I cannot rely that udev rules are applied consistently on a device.
For reference, after building libinput run sudo ./build/libinput-test-suite-runner --filter-test=lid_update_hw_on_key_multiple_keyboards run it repeatedly and at some point it will fail. The source of the issue is the udev properties for the test device *sometimes* get overwritten by the hwdb value of a rule with a lower lexical ordering. In other words: 90-something.hwdb+rules overwrites 99-myrule.rules, that shouldn't happen (or at least not randomly). For more detail, the relevant parts are: 90-foo.hwdb entry with a dmi match that assigns a property libinput:name:*Lid Switch*:dmi:*:ct9:* LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=reliable and the matching 90-foo.rules: KERNELS=="input*", \ IMPORT{builtin}="hwdb 'libinput:name:$attr{name}:$attr{[dmi/id]modalias}'" This assigns 'reliable' to the device. I also have per-device udev rules, 92-foo.rules, in this case: ATTRS{name}=="litest Lid Switch Surface3*", \ ENV{ID_INPUT_SWITCH}="1", \ ENV{LIBINPUT_ATTR_LID_SWITCH_RELIABILITY}="write_open" This overwrites 'reliable' with 'write_open'. On test-runner start, we install all the udev rules and hwdb files, run hwdb --update and then start the tests. In *most* cases, 'write_open' is correctly assigned to the device. In the failure cases, 'reliable' is assigned. Nothing changes in the udevadm test output and I've verified that the order appears to change, in the failure cases the 92-foo.rules applies before the hwdb overwrites it: ATTRS{name}=="litest Lid Switch Surface3*", ENV{ID_INPUT_SWITCH}="1", ENV{BONGO}="litest", ENV{LIBINPUT_ATTR_LID_SWITCH_RELIABILITY}="write_open" ATTRS{name}=="litest Lid Switch Surface3*", ENV{FIRSTVAL}="$env{LIBINPUT_ATTR_LID_SWITCH_RELIABILITY}" Running with this udev rule shows that FIRSTVAL is write_open but the real property is 'reliable'. This happens anywhere between 1 out of 3 and 1 out of 50, though it seems to be more common when creating/removing uinput devices like crazy. What's going on here and where could the issue lie? Thanks Cheers, Peter _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel