B@Arcitec lets discuss here
Bso the PR there needs updating
AYeah. Reading. This is a long standing issue of some kind?
Bnot really, but a bit
Bbasically in reviewing this PR i realized it's odd that all those udev rules expect the user to be in
wheel groupBthat doesn't work if you have non-admin users
Bbut that led me to think about
input group and other stuff... which users are not in by default on SilverblueBso, the new lines of this PR are all merged... but not the changed groups
AAhh. I will check it in more detail when I wake up (getting close to bed). But adding users to an extra group sounds doable.
Byeah, it's doable, just needs to be done right
AWe're interested in
input for all the device rules, or wheel too?Ano... that was a tired question
ANot wheel, of course.
Bnot wheel 
Bprobably
input is a decent choice as one could expect non-admin users to be part of it... i think they are by default on Fedora Workstation (need to check)AYeah. The hard part is how to modify existing users on a system after a rebase.
Bon Ubuntu, i think they use
plugdev but that's less common in RedHat/Fedora landADefault groups are really easy, I think. For new users.
Bit may be enough to set new defaults in the
mainconfig generated RPM and have some docs an an announcement for existing users on how to take advantageABtw just to check, is the
input group adding the main problem? Or are there other things to worry about too?Bi think the
1) it DOES exist somewhere on the silverblue system
2) users are NOT currently part of it by default
3) we want them to be
4) how to add existing users to it
5) then change the udev rules to use
input group is the issue... 1) it DOES exist somewhere on the silverblue system
2) users are NOT currently part of it by default
3) we want them to be
4) how to add existing users to it
5) then change the udev rules to use
input for controllers/keyboards/etcAHow about if we update a default file to make all new users part of
input (includes people who install via ISO), and tell "rebasing users" to run a command (similar to how nvidia rebasers must run a rpm-ostree kargs).AAlternatively we can go all the way and make some kind of systemd script that runs as root at every startup, loops all users and ensures they are part of
input.Bi mean, investigate, it COULD be argued its a bug in Silverblue/rpm-ostree system depending on the core issue
AI am on Fedora Workstation 36->37->38 host system atm, and I am in:
ASo "input" is nowhere to be seen here either.
Bwell, maybe it's not default then
AYeah I did upgrades but I started on 36 so it wasn't long ago.
Bbut we need a solution... it seems wrong that a dad (me) can't let his kids use a controller properly in our udev-rules without granting wheel
Bit's weird to me that we aren't even in a
usersYeah. I remember hearing about this
input group in other discussions. I think the udev rules have some "group=input or wheel", from my vague memory.ASo if that's the case then all they need is input.
Bthat's an option too! if we can do an OR in the group, then we can just offer documentation for "if you want this for non-admins, add them to
input group"Bi don't know how to do "group X or Y" in udev rules though
AHmm, steam's own rules don't do this:
They seem to just open it up to every user. I'll investigate more tomorrow what the
They seem to just open it up to every user. I'll investigate more tomorrow what the
input group is from. I am guessing it's specified in the udev files we're using.Bnope
Blook at...
B80-wooting.rulesBi hadn't looked closely
Bthankfully, that looks to be the only problematic file!
AChecking...
AAh yeah. So this file is saying "user must be in wheel input to get access".
AIt makes sense now. But I wonder what the implications are of doing what steam-devices udev rules did: No group.
Bso the upstream for that file (where the PR content was source from) changed that from wheel to input
Band, added some new lines
Bso that's where this came from and why i was looking
AI'll show you what Valve did.
Bbut i didn't dig deep enough to see that our other things aren't impacted, which is great
AWhat about we switch to this method instead? Any security issues?
