xbox360 controllers (suitable for GSOC?)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

xbox360 controllers (suitable for GSOC?)

wylda
Hi,
when i saw release notes stating "Support for game controllers through SDL"
immediately come up to my mind Plug & Play support for xbox360 controllers...
But probably not yet.

Sorry for asking here (no more descriptive WWN ;)
 1. what was improved through SDL?
 2. is anybody working on Plug & Play Xbox controllers support?
 3. could this be one of many GSOC topic?
 4. is it worth opening a bug report for XBOX controller support?

Regards,
W.


Reply | Threaded
Open this post in threaded view
|

Re: xbox360 controllers (suitable for GSOC?)

Stefan Dösinger-4
Hi,

> Am 11.03.2018 um 06:48 schrieb [hidden email]:
>
> Sorry for asking here (no more descriptive WWN ;)
Yeah, sorry, I stopped writing these when I became a full time Wine developer again. Feels more productive to write code. Volunteers are welcome :-)

Aric Steward implemented most of the parts. I am answering your questions from memory, but I may be wrong.

> 1. what was improved through SDL?
Aric implemented USB HID support a while ago. This contains some infrastructure in Wine for handling HID events, and it originally read HID reports from /dev/hidrawX. That had the major drawback that /dev/hidrawX is not user readable by default. Reading from /dev/input/eventX is the preferred way, but it'd require translating the higher level event data back to hidraw data. If I understand things right the SDL work reads joystick data the way it is supposed to work and feeds the data into the HID code in Wine. This way things should in theory also work on MacOS.

Recently he implemented xinput.dll on top of the already existing HID code. So xinput should in principle work.

> 2. is anybody working on Plug & Play Xbox controllers support?
I recommend to ask Aric for the state and what TODOs are left.

> 3. could this be one of many GSOC topic?
Potentially, but it depends on the amount of work that is left. There are also joystick parts in dinput.dll and winmm.dll that should be re-written on top of HID instead of their Linux/Mac specific codepaths. It's possible that this task is also already done.

> 4. is it worth opening a bug report for XBOX controller support?
I think so, yes, but check it with Wine git. Things have changed a lot recently.



Reply | Threaded
Open this post in threaded view
|

Re: xbox360 controllers (suitable for GSOC?)

Kai Krakow
Hello!

Stefan Dösinger <[hidden email]> schrieb am Mo., 12. März 2018 um 16:39 Uhr:
Hi,

> Am 11.03.2018 um 06:48 schrieb [hidden email]:
>
> Sorry for asking here (no more descriptive WWN ;)
Yeah, sorry, I stopped writing these when I became a full time Wine developer again. Feels more productive to write code. Volunteers are welcome :-)

Aric Steward implemented most of the parts. I am answering your questions from memory, but I may be wrong.

> 1. what was improved through SDL?
Aric implemented USB HID support a while ago. This contains some infrastructure in Wine for handling HID events, and it originally read HID reports from /dev/hidrawX. That had the major drawback that /dev/hidrawX is not user readable by default. Reading from /dev/input/eventX is the preferred way, but it'd require translating the higher level event data back to hidraw data. If I understand things right the SDL work reads joystick data the way it is supposed to work and feeds the data into the HID code in Wine. This way things should in theory also work on MacOS.

Recently he implemented xinput.dll on top of the already existing HID code. So xinput should in principle work.

I can confirm it working here. Games detect the gamepad and use all of its functions (e.g., rumble). Previous workarounds with dll injection are no longer needed.
 

> 2. is anybody working on Plug & Play Xbox controllers support?
I recommend to ask Aric for the state and what TODOs are left.

I'm using and Xbox One S controller with 2017 firmware. You need to use xpadneo kernel module currently to get correct button and axis mapping because the controller pairs in Android mode when paired via BT natively in Linux. But from that point one, with the SDL work (and a small patch posted here to support my model), the controller is detected as Xbox Controller out of the box.


> 3. could this be one of many GSOC topic?
Potentially, but it depends on the amount of work that is left. There are also joystick parts in dinput.dll and winmm.dll that should be re-written on top of HID instead of their Linux/Mac specific codepaths. It's possible that this task is also already done.

As far as I watched the patches, this is not done yet. Also, the controller does not seem to support directional rumble yet. Changes may have to be made to both Wine and the xpadneo driver (currently an out-of-kernel project). It also needs some fixes within Steam configuration because Steam may come up with wrong SDL mappings because it thinks the controller is in Android mode. But actually, xpadneo maps that back to standard Xbox mappings because otherwise you see inconsistent behavior based on which input library is used (xinput, dinput, etc) and which Linux device is used (jsX vs eventX).


 
> 4. is it worth opening a bug report for XBOX controller support?
I think so, yes, but check it with Wine git. Things have changed a lot recently.

Please let me know, I'd like to follow that bug report.


Regards,
Kai


Reply | Threaded
Open this post in threaded view
|

Re: xbox360 controllers (suitable for GSOC?)

Aric Stewart
In reply to this post by Stefan Dösinger-4
Hello,

Yay, somebody is using this! I was wondering how long before people started noticing XInput and SDL.


On 3/12/18 10:38 AM, Stefan Dösinger wrote:

> Hi,
>
>> Am 11.03.2018 um 06:48 schrieb [hidden email]:
>>
>> Sorry for asking here (no more descriptive WWN ;)
> Yeah, sorry, I stopped writing these when I became a full time Wine developer again. Feels more productive to write code. Volunteers are welcome :-)
>
> Aric Steward implemented most of the parts. I am answering your questions from memory, but I may be wrong.
>
>> 1. what was improved through SDL?
> Aric implemented USB HID support a while ago. This contains some infrastructure in Wine for handling HID events, and it originally read HID reports from /dev/hidrawX. That had the major drawback that /dev/hidrawX is not user readable by default. Reading from /dev/input/eventX is the preferred way, but it'd require translating the higher level event data back to hidraw data. If I understand things right the SDL work reads joystick data the way it is supposed to work and feeds the data into the HID code in Wine. This way things should in theory also work on MacOS.
>
> Recently he implemented xinput.dll on top of the already existing HID code. So xinput should in principle work.
>

Yes, SDL is implemented as a very base level (driver) support layer. So direct to HID programs as well as now XInput should work through SDL.  It works on both Linux and MacOS.

>> 2. is anybody working on Plug & Play Xbox controllers support?
> I recommend to ask Aric for the state and what TODOs are left.
>

Nobody is working on this as far as I know. I have done some of the very preliminary research on how to support it and have tried to design the parts I have implement around a future plug and play support layer. However have not made the effort to implement it.


>> 3. could this be one of many GSOC topic?
> Potentially, but it depends on the amount of work that is left. There are also joystick parts in dinput.dll and winmm.dll that should be re-written on top of HID instead of their Linux/Mac specific codepaths. It's possible that this task is also already done.

I have toyed with this a number of times, the trick is that there is a lot of knowledge required around windows driver layer, HID and things that make what may be relatively simple coding tasks hard from a baseline of understanding position.

WinMM is a clear example of something that could very successfully be re-written on top of HID and greatly improved. It should be a pretty streight forward task. It is on my TODO list once the XInput implementation sits in place for a while and proves to be successful.

>
>> 4. is it worth opening a bug report for XBOX controller support?
> I think so, yes, but check it with Wine git. Things have changed a lot recently.

Yes, if given XBOX controllers or XInput things are not working then it is worth retesting and reporting.

Thanks!
-aric