Valve Is Giving Out Their Steam Linux Games To Mesa Developers

[daniels]

The question is, why didn't they do this before? Mesa devs have had some bugs related to steam and its games, my guess is that this could have helped a lot.

To be fair, Valve had the offer on the table for quite some time, but I didn't get around to it.

[CrystalGamma]

understands understands, stay easy; also english language has to evolve... [one time "u" is red as "a" another time as "iu" another time as "u"; one time "e" is red as "i" another time as "e"; example: re-enable=rienabl]... english should be written in fonetics way: so one sound one vocal (a,e,i,o,u=a,e,i,o,u) or one single syllable (only native the English would not understand because they are mentally rigid). enough=enaf (more simple to understand). English is a language for schizophrenics.

You do know that English has 10 vowels, not 5, but only 5 vowel letters, right?
I do think that most words with 'gh' in their spelling are ridiculous though.

[Azrael5]

You do know that English has 10 vowels, not 5, but only 5 vowel letters, right?
I do think that most words with 'gh' in their spelling are ridiculous though.

though in my language = do (2 letters where o=o of "doom" not "u" as do verb; where is the sound of "gh"?: it doesn't exist but it is written: ahahahaha). So one person has to read 6 letters for 1 only syllable (my mind has to match 6 letters and one only syllable of 2 letters together: schizoph(f)renia).

Now think to though word and enough word in this last case "gh" is pronounced as "f" in the same way of "ph".... I think English has to evolve quickly as linux sy(i)stems is doing ("i" read i as "th"i"nk")

A glottologist would have difficult to attribute a logic to this language here why they invented C++, basic, cobol, machine language.

[tarceri]

Yes. In 99% of cases, especially with wireless devices that can turn off... we simply don't know the correct packet to send to the wireless device to test whether the controller is on or not. We've known how to do this with the Xbox 360 Wireless controller for years now (which I think I'm the first to figure out actually). It's frustrating that providing that information hasn't actually improved the current driver at all. I actually made a small blog post almost two years ago here: https://computerquip.wordpress.com/2...e-better-good/

Wow, I see you have spent a lot of time on this. So it seems Pierre-Loup was going to make some changes to his patches and resubmit them based on yours and others suggestions. Did that ever happen?

It does seem sad that no progress is being made on this, even though the past patches might not be perfect they seem better than the status quo. Maybe if I can show this fixes the issue in Oddworld I can convince the Oddworld developers to bug Valve about progressing the support. Its a long shot but I guess its worth a try.

[Guest]

IMHO good code is self-explanatory. But looking at the various mailing lists i subscribed it is not in most cases ...

90% of time you are correct, but the remaining 10% will still require some form of comments that explain reasoning behind the code or control flow logic.
Mailing lists are generally full of these 10%, they contain out of context patches that fix/workaround problem or add a feature. If you want your code to get in trough review, you have to make it as clear as possible, comment it properly, show the need for it be included ... etc.

Basically, if you really believe that "good code is self-explanatory", then you have only worked on small projects with small numer of devs.

[stqn]

Basically, if you really believe that "good code is self-explanatory", then you have only worked on small projects with small numer of devs.

Even with only one or two programmers, it really helps to comment things that are not *really* obvious. Especially functions themselves are rarely commented? You have to read all the code to know what they do, when they must or must not be used, what the parameters are?

[tarceri]

Yes. In 99% of cases, especially with wireless devices that can turn off... we simply don't know the correct packet to send to the wireless device to test whether the controller is on or not. We've known how to do this with the Xbox 360 Wireless controller for years now (which I think I'm the first to figure out actually). It's frustrating that providing that information hasn't actually improved the current driver at all. I actually made a small blog post almost two years ago here: https://computerquip.wordpress.com/2...e-better-good/

Hello again,

So it turns out Valves patches don't help Oddworld with xpad.

Any chance you could update the readme file for your driver in github with some instructions on how to build and install it? I haven't really played with kernel stuff before, and I'd like to see if your driver works any better with this game and if so attempt to track down why.

[computerquip]

What is the issue specifically?

[tarceri]

What is the issue specifically?

I figured out how to build and install your driver and was going to send you a pull request to add the info to the readme but I couldn't get your driver to work.

In the end I got the SteamOS driver working but I don't understand why what I did made it work, it would be great if you could help me to understand why its suddenly working with the change I made. For a full description see my blog post here: http://www.itsqueeze.com/2015/04/get...e-xpad-driver/

[computerquip]

I figured out how to build and install your driver and was going to send you a pull request to add the info to the readme but I couldn't get your driver to work.

In the end I got the SteamOS driver working but I don't understand why what I did made it work, it would be great if you could help me to understand why its suddenly working with the change I made. For a full description see my blog post here: http://www.itsqueeze.com/2015/04/get...e-xpad-driver/

The drivers on my git repository aren't complete. They're meant as a reference so I've never gotten around to actually fixing the issues with them.

xpad4 is the HID driver. The HID descriptor doesn't work. Input simply won't work.
xpad3 is probably the best driver on the repository but I think it has some issue that causes a stall somewhere in interrupt context. There's also a NULL dereference somewhere. I've just not gotten around to getting a debugging environment to figure out the source of these bugs.
xpad2 is the userspace driver, similar to xboxdrv. It was meant to showcase some changes I made to libusb's hotplug API, which I had presented on libusb's github... where it sat for about a month before I took it down due to lack of interest.

xpad360wr is the first driver I made. It has similar issues to xpad3 except is poorly organized and hard to read.

There's problems even further with my drivers in general. I don't follow the same ID as the xpad driver because the original intention was to copy the behavior of the Windows driver. I was going to basically re-implemented xinput as another proof of concept (and potentially for WINE support) but I still haven't gotten to it... and it's been two years now.

Further, the game seems to be using the legacy joystick interface for controllers. The driver may have issues but the fact that the game freezes is an issue in the game, not even xpad! I'm not sure what the game is doing that causes a freeze that could be caused directly by the driver. I don't think my driver should fix this issue either.

EDIT: Even if the driver spawns 4 controllers when it shouldn't, those controllers are still valid. It just breaks hotplugging and confuses the application as to what's actually available.