Closed NeoTheFox closed 3 years ago
erjiang
commented
3 years ago I don't think I have strong opinions about generating udev rules but I want to do a little more research into it.
As for the config location, if the goal is to better support XDG_CONFIG_HOME, why don't we just default to using XDG_CONFIG_HOME if it's set? e.g. CONFIG_HOME = os.getenv('XDG_CONFIG_HOME') or '~/.config/'? Seems like unnecessary work to need to manually pass it in as an argument.
NeoTheFox
commented
3 years ago udev rules are how every other userspace HID driver gets its permissions, for example steam.
As for config XDG_CONFIG_HOME expansion - having a config file location option is still a good idea because some people don't use an environment that sets this variable but would still prefer their configs to be elsewhere. If it's not clear in the code if no variable is provided it defaults to ~/.config/huion-keys.conf as it did before, and so the two are not mutually exclusive. I just figured if I'm adding the argument parsing I might as well get this in.
erjiang
commented
3 years ago udev rules are how every other userspace HID driver gets its permissions, for example steam.
Yes, but I'm not super familiar with the uaccess tag. That's a systemd thing, not part of udev itself, right? Do we need to give any special consideration to using this systemd behavior?
NeoTheFox
commented
3 years ago Well udev itself is now a part of systemd, this is the intended way of handling input devices since a user can use the device right away. If you want to accommodate eudev users we can use a group instead, but that means a user would have to add themselves to a group and re-login for this to apply. My opinion is the minority of people using a fork would be capable of just tweaking these rules for themselves and that would not come at an expense of the majority of people running system systems, but the final word is yours.
erjiang
commented
3 years ago Got a chance to test it out and it all seems to work. :+1:
I figured since we store models and their VID/PID values in the script itself this can be leveraged to easily create persistent udev rules to stop bothering with chown/sudo every time. Originally I wanted to delve into SETCAPs, but that would be overkill. The idea is to just output a nicely formated, up-to-date udev rules file, so the user could do this:
sudo sh -c 'python -u ./huion_keys.py --rules >> /etc/udev/rules.d/99-huion-keys.rules'And then never worry about file permissions after that. Also in this PR is a config change, adding command-line options - so might as well add some flexibility there - no breaking changes/behavior changes, although respecting XDG_CONFIG_HOME just got a bit easier for those who care!