Steering Wheel Manager oversteer adds support for more wheels and Flatpak

If 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?

If 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?

Because udev rules manage device events and those operate system wide.

With these rules you can change the behavior of your system. Its not something you want a random app to have access to.

If 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.

If 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

If 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.

Thrustmaster still requires building a separate driver, which supports only basic functionality. :(

So is "Thrustmaster", like, a dildonics company that just diversified into steering wheels, or what?

If 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).


Last edited by dziadulewicz on 16 Aug 2024 at 4:33 pm UTC

If 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.

If 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.

No 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.

So 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.

If 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.

No 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.

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.

So 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.

Oh my god. It took me a moment to appreciate the full horror of that reply.

If 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 Aug 2024 at 3:40 pm UTC

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 Aug 2024 at 5:59 pm UTC

So 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.