improve documentation for udev rule files on Linux #276
No reviewers
Labels
No labels
3rdparty
Android
API
Author does not respond
bsd
bug
build system/CI
ci-virtual-device
CMake
Contributions Welcome
Core
dependencies
device-specific
documentation
don't_merge
duplicate
enhancement
Example
Haiku
hidraw
hotplug
info required
invalid
libusb
macOS
Misc
Not an issue
question
Release
Test
Test GUI
Windows
wontfix
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-libusb/hidapi!276
Loading…
Reference in a new issue
No description provided.
Delete branch "udev"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Refer to the commit messages for details.
Lets keep .rules sample unser
udev/where it was.since this is an example, lets have an alternative example, where GROUP + MODE is used instead of 'uaccess', which is commonly known among community
don't see where
Busnumis referenced/used@ -47,6 +47,11 @@ HIDAPI has five back-ends:On Linux, either the hidraw or the libusb back-end can be used. There areThat is not a good solution because it requires explaining to (human) users that they need to add their user account to a specially named group which may vary depending on the application or distribution. This is an annoying user support burden. I know from experience.
TAG+="uaccess"does not have this problem.oh, I removed it, but not from the comment. Good catch
I'm not saying this is a bad solution. For some scenarios it is a great solution. But other than that there is no other reasons to limit users from available options.
Apparently you don't need to run unit-tests for your software from CI over SSH, using a real device connected to the build machine, where access to the device is expected exclusively from a remote session.
Having access setup for a specific USER/GROUP is a great solution for that case too.
Does anyone actually do that?
At least one suck user for your service.
Okay, I added a comment to the end of the file.
@ -0,0 +16,4 @@KERNEL=="hidraw*", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="003f", TAG+="uaccess"# Once done, optionally rename this file for your application, and drop it into# /etc/udev/rules.d. Note that these rules must have priorty before 70-uaccess.rules@Be-ing I hope you do not mind the tag. Can you help explain the following:
@ -0,0 +16,4 @@KERNEL=="hidraw*", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="003f", TAG+="uaccess"# Once done, optionally rename this file for your application, and drop it into# /etc/udev/rules.d. Note that these rules must have priorty before 70-uaccess.rulesI don't recall the reason for this. I'm not sure we ever dug deep to figure out exactly what the issue was, but IIRC we stumbled on this shipping the udev rule file for Mixxx.
@ -0,0 +16,4 @@KERNEL=="hidraw*", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="003f", TAG+="uaccess"# Once done, optionally rename this file for your application, and drop it into# /etc/udev/rules.d. Note that these rules must have priorty before 70-uaccess.rulesIf you figure this out, it would be great if you open a pull request to clarify the documentation in this example udev rule file.
@ -0,0 +16,4 @@KERNEL=="hidraw*", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="003f", TAG+="uaccess"# Once done, optionally rename this file for your application, and drop it into# /etc/udev/rules.d. Note that these rules must have priorty before 70-uaccess.rulesI've been having problems using the
hidrawin general so I came here more as a "what am I doing wrong" step. I'll surely improve if I get further. 🍺@ -0,0 +16,4 @@KERNEL=="hidraw*", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="003f", TAG+="uaccess"# Once done, optionally rename this file for your application, and drop it into# /etc/udev/rules.d. Note that these rules must have priorty before 70-uaccess.rulesIs this for LMMS?
@ -0,0 +16,4 @@KERNEL=="hidraw*", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="003f", TAG+="uaccess"# Once done, optionally rename this file for your application, and drop it into# /etc/udev/rules.d. Note that these rules must have priorty before 70-uaccess.rulesIt's actually for another project (QZ Tray), which uses hidapi through hid4java.
@ -0,0 +16,4 @@KERNEL=="hidraw*", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="003f", TAG+="uaccess"# Once done, optionally rename this file for your application, and drop it into# /etc/udev/rules.d. Note that these rules must have priorty before 70-uaccess.rulesI'm pretty sure it is bacause of the use of
TAG+="uaccess"- this tag is handled by the70-uaccess.rulesfile70-uaccess.rules@ -0,0 +16,4 @@KERNEL=="hidraw*", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="003f", TAG+="uaccess"# Once done, optionally rename this file for your application, and drop it into# /etc/udev/rules.d. Note that these rules must have priorty before 70-uaccess.rules@Youw thanks for the tip... I stumbled upon this bug report which seems to state something similar.
https://github.com/systemd/systemd/issues/4288#issuecomment-348166161
@ -0,0 +16,4 @@KERNEL=="hidraw*", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="003f", TAG+="uaccess"# Once done, optionally rename this file for your application, and drop it into# /etc/udev/rules.d. Note that these rules must have priorty before 70-uaccess.rulesAha, so I haven't actually looked up the documentation for
70-uaccess.rules, I just assumed its purpose based on the documentation as suggested by this PR.Thanks for pointing out to that comment. It appears my assumption is absolutely correct, but regarding a different file:
73-seat-late.rules.I'll update a documentation once again.
@ -0,0 +16,4 @@KERNEL=="hidraw*", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="003f", TAG+="uaccess"# Once done, optionally rename this file for your application, and drop it into# /etc/udev/rules.d. Note that these rules must have priorty before 70-uaccess.rulesOn that note: it looks like
70-uaccess.rulesjust automatically adds theuaccesstag to a few known devices/device types.Tangentially related: I requested a means for sandboxed applications to access HID devices without installing a udev rule file.