28 Replies
@Arcitec lets discuss here
so the PR there needs updating
Yeah. Reading. This is a long standing issue of some kind?
not really, but a bit
basically in reviewing this PR i realized it's odd that all those udev rules expect the user to be in
wheel group
that doesn't work if you have non-admin users
but that led me to think about input group and other stuff... which users are not in by default on Silverblue
so, the new lines of this PR are all merged... but not the changed groupsAhh. I will check it in more detail when I wake up (getting close to bed). But adding users to an extra group sounds doable.
yeah, it's doable, just needs to be done right
We're interested in
input for all the device rules, or wheel too?
no... that was a tired question
Not wheel, of course.not wheel 🙂
probably
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)Yeah. The hard part is how to modify existing users on a system after a rebase.
on Ubuntu, i think they use
plugdev but that's less common in RedHat/Fedora landDefault groups are really easy, I think. For new users.
it may be enough to set new defaults in the
main image... maybe as part of a config generated RPM and have some docs an an announcement for existing users on how to take advantageBtw just to check, is the
input group adding the main problem? Or are there other things to worry about too?i think the
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/etcHow 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).
Alternatively 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.i mean, investigate, it COULD be argued its a bug in Silverblue/rpm-ostree system depending on the core issue
I am on Fedora Workstation 36->37->38 host system atm, and I am in:
So "input" is nowhere to be seen here either.
well, maybe it's not default then
Yeah I did upgrades but I started on 36 so it wasn't long ago.
but 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 🙂
it's weird to me that we aren't even in a
users group anymoreYeah. 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.
So if that's the case then all they need is input.that'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"
i don't know how to do "group X or Y" in udev rules thoughHmm, 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
input group is from. I am guessing it's specified in the udev files we're using.nope
look at...
80-wooting.rules
i hadn't looked closely
thankfully, that looks to be the only problematic file!Checking...
Ah yeah. So this file is saying "user must be in wheel input to get access".
It makes sense now. But I wonder what the implications are of doing what steam-devices udev rules did: No group.
so the upstream for that file (where the PR content was source from) changed that from wheel to input
and, added some new lines
so that's where this came from and why i was looking
I'll show you what Valve did.
but i didn't dig deep enough to see that our other things aren't impacted, which is great
https://pb.envs.net/?a7d37687b9d53a8b#CcUQRXKewZJ19b7ajpYY1za3uWWUnu1orDsHmrMhdejV
What about we switch to this method instead? Any security issues?
It literally looks harmless. It's just game devices in that wooting file?