[Bug] Most rules in 50-qmk.rules are missing MODE and GROUP for non-systemd distros

[ismay]

Describe the Bug

The udev rule in https://github.com/qmk/qmk_firmware/blob/master/util/udev/50-qmk.rules#L23 does not allow my moonlander to be flashed. When trying to do it fails with:

  dfu-util: Cannot open DFU device 0483:df11 found on devnum 9 (LIBUSB_ERROR_ACCESS)
  dfu-util: No DFU capable USB device available

This is after moving 50-qmk.rules to /etc/udev/rules.d and rebooting. All in all it seems that the default udev rules shipped with qmk_firmware are not sufficient for flashing a moonlander with my setup.

Keyboard Used

zsa/moonlander

Link to product page (if applicable)

No response

Operating System

Void Linux

qmk doctor Output

❯ qmk doctor
Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.2
Ψ QMK home: /home/ismay/code/github.com/qmk/qmk_firmware
Ψ Detected Linux (Void Linux).
Ψ Testing userspace candidate: /home/ismay/code/git.sr.ht/~ismay/qmk_userspace -- Valid `qmk.json`
Ψ QMK userspace: /home/ismay/code/git.sr.ht/~ismay/qmk_userspace
Ψ Userspace enabled: True
Ψ Git branch: master
Ψ Repo version: 0.24.7
⚠ The official repository does not seem to be configured as git remote "upstream".
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 9.3.0
Ψ Found avr-gcc version 9.3.0
⚠ We do not recommend avr-gcc newer than 8. Downgrading to 8.x is recommended.
Ψ Found avrdude version 7.0
Ψ Found dfu-programmer version 0.7.2
Ψ Found dfu-util version 0.11
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2023-04-15 13:48:04 +0000 --  (11edb1610)
Ψ - lib/chibios-contrib: 2023-11-27 18:15:44 +0100 --  (9d7a7f90)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 --  (e2239ee6)
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 --  (549b97320)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 --  (819dbc1)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 --  (c2e3b4e)
Ψ - lib/pico-sdk: 2023-02-12 20:19:37 +0100 --  (a3398d8)
Ψ - lib/lvgl: 2022-04-11 04:44:53 -0600 --  (e19410f8)
Ψ QMK is ready to go, but minor problems were found

Is AutoHotKey / Karabiner installed

• AutoHotKey (Windows)
• Karabiner (macOS)

Other keyboard-related software installed

No response

Additional Context

No response

[ismay]

After debugging and help in the voidlinux channel I found out that the problem occurs because I'm not using systemd. In that case, TAG+="uaccess" does not have any effect. Instead, what works for users who don't use systemd is adding MODE="0660", GROUP="plugdev". Strangely enough this is already present for one rule: https://github.com/qmk/qmk_firmware/blob/master/util/udev/50-qmk.rules#L71, but not for the other ones.

For these udev rules to be fully compatible with both systemd based distros and other distros, both methods should be present. So for the moonlander for example, the full rule should be:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", TAG+="uaccess", MODE="0660", GROUP="plugdev"

I'll leave a link to this discussion: #12828 (review), where the addition of the one rule that does add MODE and GROUP was discussed. What was omitted from that discussion is that TAG+="uaccess" only has an effect for distros built on top of systemd. Since not everyone uses systemd, MODE and GROUP should still be present.

[sigprof]

Alternatively, you could install the elogind package (and reboot after that) to make the existing udev rules work.

[ismay]

Alternatively, you could install the elogind package (and reboot after that) to make the existing udev rules work.

Sure. Though you'll probably need to do more than just install it, and you've probably not got it installed because you want to use something else. In all likelihood, users will either not know why this is breaking and have to debug it, or know why it's breaking and add the group and mode themselves. So it's mostly inconvenient to end users when it's quite easily fixed for everyone with a couple minor additions on qmk's side.

[tzarc]

In its current form we cannot accept this PR. This invalidates other distro's that don't set up a plugdev group -- anything systemd-based should be running with TAG+="uaccess" instead, as per the systemd developers (https://bugzilla.redhat.com/show_bug.cgi?id=815093#c2).

For example, with my main Fedora machine I don't have a plugdev group -- if we merge this PR should I subsequently raise a bugfix PR reverting to TAG+="uaccess" as that fixes my system?

The vast majority of distros use systemd nowadays, and whilst you may not find that selection palatable, you're the outlier.

From your perspective I'd suggest manually modifying the rules and installing that as per your system requirements, or figuring out an automated way to select one of two different rules files -- with preference being the TAG+="uaccess" route wherever available.

---

EDIT: Whoops, should've been on the PR. I have too many tabs open, sigh.