Steering Wheel Manager oversteer adds support for more wheels and Flatpak

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

Quoting: dziadulewicz

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

Quoting: dziadulewicz

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

Quoting: nwildner

Quoting: dziadulewicz

QuoteIf 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

Quoting: dziadulewicz

Quoting: nwildner

Quoting: dziadulewicz

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

Quoting: tfk

Quoting: dziadulewicz

Quoting: nwildner

Quoting: dziadulewicz

QuoteIf 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 August 2024 at 4:33 pm UTC

Quoting: dziadulewicz

Quoting: tfk

Quoting: dziadulewicz

Quoting: nwildner

Quoting: dziadulewicz

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

Quoting: tfk

Quoting: dziadulewicz

Quoting: tfk

Quoting: dziadulewicz

Quoting: nwildner

Quoting: dziadulewicz

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