Fedora SilverBlue does not include Steam-Devices and OpenRGB-Udev-Rules as default layered, which prevents complete integration of gaming devices and lighting systems.
• Gaming devices and lighting systems do not function correctly due to the lack of these layers. • Require manual installation, which can cause issues for novice users.
Proposed:
Incorporate Steam-Devices and OpenRGB-Udev-Rules as default in Fedora SilverBlue to ensure complete integration of gaming devices and lighting systems.
Rationale:
• Enhances the user experience with more automated integration. • Facilitates the use of gaming devices and lighting systems without requiring additional installation.
Priority: High
This inclusion would be essential for improving the user experience with Fedora SilverBlue, particularly for those using gaming devices and lighting systems.
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
steam-devices
openrgb-udev-rules can be added at any time, it's already in Fedora.
openrgb-udev-rules
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+.
Metadata Update from @ngompa: - Issue assigned to siosm - Issue close_status updated to: Fixed - Issue set to the milestone: Fedora 42 - Issue status updated to: Closed (was: Open) - Issue tagged with: easyfix, experience, packaging
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
Metadata Update from @linuxkernel94: - Issue status updated to: Open (was: Closed)
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.
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.
Log in to comment on this ticket.