xbox360 controllers (suitable for GSOC?)

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.

[Stefan Dösinger]

Hi,
> Am 11.03.2018 um 06:48 schrieb [e-mail]:
>
> 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.
> - 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.
> - is anybody working on Plug & Play Xbox controllers support?

I recommend to ask Aric for the state and what TODOs are left.
> - 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.
> - 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.

[Kai Krakow]

Hello!

Stefan Dösinger  schrieb am Mo., 12. März 2018
um 16:39 Uhr:
> Hi,
> > Am 11.03.2018 um 06:48 schrieb [e-mail]:
> >
> > 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.
> > - 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.
> - 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.
> - 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).

xpadneo: https://github.com/atar-axis/xpadneo
> > - 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

[Aric Stewart]

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 [e-mail]:
> >
> > 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.
> > - 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.
> > - 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.
> > - 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.
> > - 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