If reporting issues against Silverblue or Kionite (atomic desktops in general as this issue isn't Silverblue specific) please use https://gitlab.com/fedora/ostree/sig/-/issues/ instead. This issue tracker is only used for Fedora Workstation (the regular one, not the atomic one).

But generally Silverblue follows what's preinstalled on Workstation (we don't try add extra things). So this might stay in this issue tracker if you want to pursue the preinstallation of those packages on Workstation.

Ok thanks, I can say this affects Workstation as well so we can leave it here.

steam-devices is in package review right now: https://bugzilla.redhat.com/show_bug.cgi?id=2326622

openrgb-udev-rules can be added at any time, it's already in Fedora.

What I don't understand about the request is if they will be installed by default, I don't want to layer them on Silverblue and I think this is confusing a lot of users when installing steam as a flatpak for example

Hi Neal

Could we have these installed by default?

It's particularly problematic for Atomic variants of Fedora when this isn't included, as both are open-source packages and must be layered, otherwise the apps will not work.

Reference: https://discussion.fedoraproject.org/t/silverblue-solution-for-upstream-udev-rules-steam-devices-openrgb/35576/2

These should be added to hardware support composition groups so that they're automatically present across the board.

https://pagure.io/fedora-comps/pull-request/1101

This is done for F42+.

I just wanted to express my gratitude to you as this was a very important feature to me, thank you so much.

Well bad news then, because we have a follow-up: https://pagure.io/fedora-workstation/issue/473

This change has been reverted for now. Feel free to discuss further here.

We also have a parallel issue report here: https://gitlab.com/fedora/ostree/sig/-/issues/71

From the revert issue:

Came across this just now, so let's answer at least @catanzaro's questions: Quick check of the steam-devices package includes this line in 60-steam-input.rules:

# Steam Controller udev write access
KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess", OPTIONS+="static_node=uinput"

Can't seem to find any linkable documentation for uaccess but it means that logind will grant access to the device to the currently active user (as seen by logind). Previously /dev/uinput was only accessible to the root user.

The implication of this is that if this package is installed, any logged in user can create a new evdev kernel device via /dev/uinput. This device will be treated as if it was plugged in hardware by virtually all of the userspace stack. There are no revocation facilities for this, so the device created stays around until the process closes the uinput fd.

As to what you can do with uinput? Pretty much anything, the libinput test suite for example uses uinput to emulate devices to make sure things work as expected, we have libinput record and libinput replay that allow us to capture any input device and replay it locally as if it was plugged in. That's (iirc) what steam does (legitimately) - it parses the HID protocol from the steam devices and converts it into a uinput device that will then look like a normal device.

A few things that I can think of beyond the "create any type of device that can send any input event at any time":
- creating enough uinput device means you run out of minors for the evdev node so plugging in a physical device won't do anything (haven't tested this though).
- the way compound devices work means if I have a uinput device that holds a button or key down, that button/key effectively becomes unusuable - compositors usually trigger a press on first down and release on last up. It's 20 LOC for any user to DoS a button.
- I had a small tool once that created random uinput devices with the intention of making sure libinput can handle odd devices. I ended up crashing the kernel so often that I had to drop the idea. Creating and destroying dozens uinput devices really fast is probably still a good way to crash things though admittedly I haven't tested this in ages. edit: found it: fuzzydevice

uinput is intended functionality when you have steam devices that you want working. Having /dev/uinput available to any user ever logged in on a system is a bit hairy.

The quick check I did didn't show OpenRGB to do the same thing, those seem to have the hidraw access rules only. These are behind vid/pid checks and appear to be limited to OpenRGB so the only drawback here is that any user could send harmful commands to your keyboard - but that's IMO a reasonable trade-off to make them work.

Given the concerns raised here around security, maintainability, and upstream ownership of udev rules for gaming devices (Steam, OpenRGB, etc.), I’d like to suggest that Fedora consider adopting game-devices-udev as a clean and centralized solution.

https://codeberg.org/fabiscafe/game-devices-udev

This project is:

Actively maintained under the freedesktop umbrella

Designed to unify and modernize udev rules for game controllers (Steam Controller, Xbox, PlayStation, etc.)

Already replacing steam-devices in other distributions (e.g. Arch Linux)

Structured and reviewable — directly addressing the “who maintains this?” and “how do we track changes?” concerns raised here

Compatible with Flatpak and immutable systems like Silverblue, where users currently lack controller support without manual fixes

Importantly, adopting this would also eliminate the persistent warning seen by users launching Steam from Flatpak:

"Your system is missing the udev rules required to support some Steam Input devices..."

That message appears because the required udev rules are not present in the host system — something game-devices-udev would solve in a clean, upstreamable way.

By adopting this package, Fedora would:

Improve out-of-the-box controller support for thousands of users

Avoid fragmented or unmaintained udev rule sets

Reduce duplication across distros

Address real UX issues without compromising system security

Please consider evaluating game-devices-udev as a more scalable, secure, and user-friendly solution. I’m happy to assist with testing if needed.

Hi @whot, do you have time to look into game-devices-udev? Hopefully this project does not have the same problems you complained about in #473?

@catanzaro I had a quick look at some of those rules and there are two parts here:

A bunch of udev rules that set uaccess for specific, named devices. This is a great idea because a) it narrows down which devices have uaccess to a specific known set and b) moves it into a separate package users can install when they actually need this.

As above, whether the user should be able to write commands to a device is a tricky question with multiple answers. So failing full hidraw revoke integration this is IMO the best approach.

However, that package also has the uinput uaccess rule (71-uinput-dev-early-creation.rules) so we're back to square one where any logged in user can create uinput devices without further checks. But if it's in a separate (ideally leaf) package that at least means it needs to be intentionally installed.

The request here is to install the package by default.

Here is the explanation for why that rule exists. I don't understand udev and don't know how we should proceed here.

Hi @linuxkernel94, I think the outcome here is we're specifically not OK with 71-uinput-dev-early-creation.rules. I suppose we could add the package with that rule patched out, but I suspect that is not going to be what gamers actually want.

Earlier comment from you slipped through, apologies. A bit more explanation:

Here is the explanation for why that rule exists

There are multiple components here:
- GROUP="steam", - assign to the steam group
- OPTIONS+="static_node=uinput" - create a static node instead of on-the-fly, see the explanation in the linked comment

but the current rule we're talking about has instead of the GROUP assignment:
- TAG+="uaccess"

The static_node bit is uncontroversial because it's needed for the other half.

The GROUP assignment is - well, up to the user/admin to decide whether they want to add a user to the group and give them access. The TAG+=uaccess gives every user access if they're logged in.

GROUP is better because it requires explicit action to add a user (though that user can then create uinput devices even over ssh). TAG+=uaccess is better because it allows any user access provided they're logged in.

And now s/better/worse/ and the above paragraph is equally true :)