If you have a Steering Wheel, oversteer feels like an essential tool on Linux to allow you to configure it properly and a new release is out with version 0.8.3. As long as you have the right drivers installed, it can work with a lot of wheels and pedals. With features to help you manage rotation range, emulation/working modes, force feedback and lots more.
The latest release includes these changes:
- Initial Support for Cammus C5 Wheel by @spikerguy in #185
- Removed device_manager.py swap file by @jo5huajohn in #187
- fix(udev): use new driver name by @jinnko in #194
- Add Thrustmaster TS-XW Racing Wheel by @yassineimounachen in #200
- Flatpak Port by @jo5huajohn in #198
- Flatpak submission fixes by @jo5huajohn in #211
- Fix thrustmaster udev driver key by @adam820 in #212
Check it out on GitHub and now Flathub too. If you install it via the new Flatpak package from Flathub, you still need to set up some udev rules from the GitHub.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
Quoting: Purple Library GuySo is "Thrustmaster", like, a dildonics company that just diversified into steering wheels, or what?I actually tried using a steering wheel in that manner, but it was a bad idea, it was drivin' me nuts.
5 Likes, Who?
Quoting: Purple Library GuyQuoting: tfkNo they don't. For one thing, normal people don't install Windows. The computer they get at Best Buy or off the internet has Windows preinstalled. If anything goes wrong with it, they get help.Quoting: dziadulewiczQuoting: tfkQuoting: dziadulewiczQuoting: nwildnerQuoting: dziadulewiczQuoteIf you install it via the new Flatpak package from Flathub, you still need to set up some udev rules from the GitHub.
Now this is not good again for normal users; why are these "udev rules" (whatever they are) not just included with the Flatpak?
The fact here is that Oversteer do have udev rules - https://github.com/berarma/oversteer/tree/master/data/udev - but Flatpaks do not distribute/install udev rules and that is by design - https://github.com/flatpak/flatpak/issues/961 .As @tfk pointed out on the previous comment, udev access requires operating system admin and there is no API/ABI for the user to manipulate it.
Flatpaks use a different philosophy and they don't install stuff around normal configuration directories like `/etc`.
Also, it is hard to track `udev` rules for every existing device and software on earth in a centralized fashion, and some of them fall into more generic rules like "USB Input device" and you have to make customization that would apply to your specific device. That's why there is no curated list of udev rules for every device that exists, and it is up to the Linux Distribution providers to create a packages with specific udev rules if you think those oversteer udev rules should be bundle on every distribution
Some distros provide a really good amount of Udev rulesets for different devices. Examples:
- retroarch-autoconfig-udev-git - https://aur.archlinux.org/packages/retroarch-autoconfig-udev-git - Rules to autoconfig usb and bluetooth gamepads for retroarch.
- nintendo-udev - https://aur.archlinux.org/packages/nintendo-udev - Rules for joycons (and to fix controller ownership for steam). I can confirm this also works for Datafrog and 8BitDo controllers as well.
Udev rules can also be pretty destructive as well because it also depends on systemd changes. I had a 100% CPU usage experience in the past with OpenRGB keyboard backlight rules but the developer fixed it really quickly - https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/4166 - I think this is a good reason to not bundle "by default" millions of udev rules that target specific devices.
So it will forever be an issue and manual tinkering is required? What about Snap? Udev workaround in Snaps
That's the thing. I don't see this as a problem. The only external entity I trust with this is my distribution packaging team.
The rest I want to inspect and define myself.
An example I can give is my Wooting keyboard. Wooting provides an appimage for their management tool. But the udev rules are listed on their website. They don't try to force these rules on my system via an installer.
And that is good because ultimately I'm the one who is responsible for my system.
What do you mean you don't see this as a problem? This is not about you and me (seasoned Linux users). This means difficulty to install software with required (basic) functionality. So at least Flatpak does not suit this application.
Normal people will NEVER tinker if the installation package does not suffice installing it.
I think we have a MAJOR problem here once more if this same issue touches many more apps. Steering Wheel Manager is the only truly recommended Linux app on what it does as alternative to Windows equivalents (where normal people click and install and start to use it with all functionality).
And yet, 'normal' people, who install Windows, open a command window during installation to avoid having to register a online Windows account.
I see where you're coming from. I like these kind of problems. I think I have a solution. These udev rules should be part of the kernel driver. Take for example this thrustmaster one.
https://github.com/cazzoo/hid-tmff2
If the rules were documented here, these rules can be checked by the tech savvy user.
For now this kernel driver has to be built from source. But when it has been developed far enough, it could be proposed to the kernel developers. When accepted, it is then part of the kernel.
The devs could then create a package which deploys these rules. The distro maintainers could package it in turn to make it available to their distro. This would then add an extra layer of auditing for the general user.
The end user would still need to install the package but it would be easier to follow then the current situation.
That's the best alternative I can come up with.
4 Likes, Who?
Quoting: whizseOh my god. It took me a moment to appreciate the full horror of that reply.Quoting: Purple Library GuySo is "Thrustmaster", like, a dildonics company that just diversified into steering wheels, or what?I actually tried using a steering wheel in that manner, but it was a bad idea, it was drivin' me nuts.
2 Likes, Who?
Quoting: dziadulewiczQuoting: nwildnerQuoting: dziadulewiczQuoteIf you install it via the new Flatpak package from Flathub, you still need to set up some udev rules from the GitHub.
Now this is not good again for normal users; why are these "udev rules" (whatever they are) not just included with the Flatpak?
The fact here is that Oversteer do have udev rules - https://github.com/berarma/oversteer/tree/master/data/udev - but Flatpaks do not distribute/install udev rules and that is by design - https://github.com/flatpak/flatpak/issues/961 .As @tfk pointed out on the previous comment, udev access requires operating system admin and there is no API/ABI for the user to manipulate it.
Flatpaks use a different philosophy and they don't install stuff around normal configuration directories like `/etc`.
Also, it is hard to track `udev` rules for every existing device and software on earth in a centralized fashion, and some of them fall into more generic rules like "USB Input device" and you have to make customization that would apply to your specific device. That's why there is no curated list of udev rules for every device that exists, and it is up to the Linux Distribution providers to create a packages with specific udev rules if you think those oversteer udev rules should be bundle on every distribution
Some distros provide a really good amount of Udev rulesets for different devices. Examples:
- retroarch-autoconfig-udev-git - https://aur.archlinux.org/packages/retroarch-autoconfig-udev-git - Rules to autoconfig usb and bluetooth gamepads for retroarch.
- nintendo-udev - https://aur.archlinux.org/packages/nintendo-udev - Rules for joycons (and to fix controller ownership for steam). I can confirm this also works for Datafrog and 8BitDo controllers as well.
Udev rules can also be pretty destructive as well because it also depends on systemd changes. I had a 100% CPU usage experience in the past with OpenRGB keyboard backlight rules but the developer fixed it really quickly - https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/4166 - I think this is a good reason to not bundle "by default" millions of udev rules that target specific devices.
So it will forever be an issue and manual tinkering is required? What about Snap? Udev workaround in Snaps
I don't think, so.
I think flatpack will go the android path and ask for a specific permission.
Another thing I can see happening is a containerized udev project(sounds crap to do, but fully within the flatpack mission).
Edit: see the comment of @tfk he's more knowledgable about the subject than I'm and has a better and less complicated solution.
Last edited by LoudTechie on 17 August 2024 at 3:40 pm UTC
0 Likes
Anyone happen to know how the HORI wheel support is these days? The one I have comes with PS3/PS4 and some generic mode and I had some partially success using it on Linux some years back, but it wasn't really that enjoyable due to various issues.
Maybe time to try it again with this nice tool?
Last edited by Julius on 18 August 2024 at 5:59 pm UTC
Maybe time to try it again with this nice tool?
Last edited by Julius on 18 August 2024 at 5:59 pm UTC
0 Likes
Quoting: Purple Library GuySo is "Thrustmaster", like, a dildonics company that just diversified into steering wheels, or what?
No, Thrustmaster have been selling flightsticks since the '90s, pivoting (if you'll pardon the pun) to a wider variety of game controllers (gamepads and wheels) around the turn of the millennium. They're not as big a name as Logitech, but they're still quite established.
0 Likes
Patreon
PayPal
See more from me