The real problem behind all this is that banks control what we can do with our money. There are increasingly more restrictions to what we can do with it, including cash withdrawal, while banks have increasing control.

View this comment - View article - View full comments

Who would have thought that these companies that pay with our money are a bunch of liars.

View this comment - View article - View full comments

While most comments here imply that Nintendo used extortion, I think it's just an economical agreement. That's how it looks. Nintendo must have offered him a good payment to stop developing the emulator and shutting down everything under his control. Why pay an army of lawyers if you can pay just the main dev?

View this comment - View article - View full comments

Does it still need Python2? Does the SD ship Python2?

And what's up with the version numbers? 0.4.8 and then 0.4.8.9 as a pre-release?

View this comment - View article - View full comments

Developers which can't do proper Linux ports usually have trouble doing Windows ports too. The main issue is frquently in the way the source code is built.

It's a matter of having complete control over the port or adding more complexity and dependencies on external software. Normally a company wouldn't want it but when they don't care much about the users they can opt for the latter.

This is better than leaving the port to die but don't tell everyone that this is the best technically savy decission because it isn't. No company wouldn't run their product through something like Proton on Windows even if it would make it easier for them to support different Windows versions and configurations. They care too much for Windows users to do that.

View this comment - View article - View full comments

Quoting: subSo this won't be accepted in the kernel if *only* a proprietary user space drivers is available.
Mind that AMD only got their kernel driver mainlined as it provides a proprietary AND open-source
user space driver using the same API.

That's not true, drivers don't get rejected for that reason. The only reason it can't be streamlined is that the code doesn't follow Linux coding conventions. The driver as it is can be used by other software, not only the Nvidia propietary drivers. I guess it could be even used by Mesa. We'll see.

View this comment - View article - View full comments

Quoting: Purple Library Guy

Quoting: toorMaybe we should understand

it does not support SteamOS

as "don't ask us if it doesn't work, we are not responsible of your experience with the game on steamOS"

Sure, but then how should we understand

it cannot be played on Steam Deck

The same. It seems the developers are running out of ways to say "we don't want to hear complaints from you".

View this comment - View article - View full comments

Quoting: JpxsonI feel bad for Feral, I'm guessing Proton will be selected for all their games.

I think you've missed the point. Valve will test the native port and use it as long as it passes the tests for the Steam Deck. They will not choose the one with best performance on anyone's PC or based on what works best for some users. It's a validation program for the Steam Deck.

In addition, they're old games, I don't think Feral will be making any money from those games. Their porting licenses are expiring, and games that were already in our libraries won't affect Feral's income.

View this comment - View article - View full comments

Quoting: cazzoo

Quoting: berarmaI'm open to suggestions for a better wording. Being supported by Oversteer doesn't mean that the wheel is fully working, although the axes and buttons normally do and that's the reason to add them. The README says to check support for those wheels in the respective projects. I've changed the wording many times to try to make it clear but someone will always get it wrong I guess. I don't want to mislead anyone but I'd like to get more people to know these projects.

No offense here, I understand Oversteer is a wrapper tool to help showing devices inputs and eventually settings them up.
I intended to use it as well when I discovered that T500RS driver didn't exists...

My best proposal would be to add some side notes to the drive compatibility list to explain the support is much limited; at least for the T500RS one.

I can't commit to showing updated information about wheel support in my README. I don't have the time nor the devices to test myself or do the research. I could remove all references to non Logitech devices but this wouldn't help the other projects. What would be best?

View this comment - View article - View full comments

Quoting: cazzooGood article, unfortunately not 100%: accurate, and this is not your fault. Oversized GitHub page mentioned support of T500RS while it is not.

Indeed I am the one working on T500RS driver and I can say we're far from getting working driver... Kimplul did a great job for T300RS and even though T500 is based in the same code it's unfortunately not working straight away.
USB reverse engineering is much of a work and I don't have many time to dedicate these days.

I hope this comment will help people looking for it working for T500

I'm open to suggestions for a better wording. Being supported by Oversteer doesn't mean that the wheel is fully working, although the axes and buttons normally do and that's the reason to add them. The README says to check support for those wheels in the respective projects. I've changed the wording many times to try to make it clear but someone will always get it wrong I guess. I don't want to mislead anyone but I'd like to get more people to know these projects.

View this comment - View article - View full comments