I'm going to have a go at Chorus. Don't know anything about it yet. But it's verified so the devs seem to have made the effort.

View this comment - View article - View full comments

It's because EA hates us.

View this comment - View article - View full comments

Why ignore a platform that's sold multiple millions, and is clearly just continuing to fly off the shelves?

Cause Sweeney hates us.

View this comment - View article - View full comments

The SBAT value is not applied to dual-boot systems that boot both Windows and Linux and should not affect these systems. You might find that older Linux distribution ISOs will not boot.


They mention that only old Linux ISOs won't boot. Why do I get the feeling that they didn't even test?

View this comment - View article - View full comments

Quoting: Purple Library Guy

Quoting: tfk

Quoting: dziadulewicz

Quoting: tfk

Quoting: dziadulewicz

Quoting: nwildner

Quoting: dziadulewicz

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 [External Link] - but Flatpaks do not distribute/install udev rules and that is by design - https://github.com/flatpak/flatpak/issues/961 [External Link] .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 [External Link] - Rules to autoconfig usb and bluetooth gamepads for retroarch.
- nintendo-udev - https://aur.archlinux.org/packages/nintendo-udev [External Link] - 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 [External Link] - 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 [External Link]

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 [External Link]

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.

View this comment - View article - View full comments

Quoting: dziadulewicz

Quoting: tfk

Quoting: dziadulewicz

Quoting: nwildner

Quoting: dziadulewicz

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 [External Link] - but Flatpaks do not distribute/install udev rules and that is by design - https://github.com/flatpak/flatpak/issues/961 [External Link] .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 [External Link] - Rules to autoconfig usb and bluetooth gamepads for retroarch.
- nintendo-udev - https://aur.archlinux.org/packages/nintendo-udev [External Link] - 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 [External Link] - 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 [External Link]

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.

View this comment - View article - View full comments

Quoting: dziadulewicz

Quoting: nwildner

Quoting: dziadulewicz

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 [External Link] - but Flatpaks do not distribute/install udev rules and that is by design - https://github.com/flatpak/flatpak/issues/961 [External Link] .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 [External Link] - Rules to autoconfig usb and bluetooth gamepads for retroarch.
- nintendo-udev - https://aur.archlinux.org/packages/nintendo-udev [External Link] - 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 [External Link] - 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 [External Link]

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.

View this comment - View article - View full comments

Quoting: dziadulewicz

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.

View this comment - View article - View full comments

Just read some post on the Steam forums. They got drivers now but are still complaining.

It's a small difference in attitude I'm observing here.

We get native Linux support for something, we say thanks and start to give feedback on any issues we encounter.

They get Windows support for something, they're like "About time!". And when there are issues they're like "It won't work! You suck! I'm selling my device!".

I can see why Valve had this on low priority.

View this comment - View article - View full comments

Got a cat here.
Friends passing by can touch her and click Like to pet her once.
　　　　 　　 ＿＿
　　　 　　／＞　　フ
　　　 　　| 　_　 _ l
　 　　 　／` ミ＿xノ
　　 　 /　　　 　 |
　　　 /　 ヽ　　 ﾉ
　 　 │　　|　|　|
　／￣|　　 |　|　|
　| (￣ヽ＿_ヽ_)__)
　二つ

View this comment - View article - View full comments