xpadneo

xpadneo copied to clipboard

I would really appreciate if somebody, who is experienced there, would help me to push this driver into the kernel.

@kakra

Not really experienced with the process itself but I could start with a code and style review, and research the rest of the requirements.

Hooray - I would really appreciate that! I think the driver is stable enough now.

https://lore.kernel.org/patchwork/patch/973394/#1175786

Did you ever submit your Bluetooth patch upstream? I'm interested in helping with that.

Hey @cgutman, unfortunately I haven't since patches to the bluetooth part of linux seem to require some additional verfication process.

I ordered the PTS dongle, so I can do the verification once I receive it.

Wonderful :) Tell me when it arrived.

Is this on kernel already? Saw an article about kernel 4.20 and shows that xbox one s controller rumble is supported... I am a bit confused.

it isn't, but yes valve added basic rumble support in 4.20 but none of the other things like battery indication, mapping correction and so on. :)

Hey, are you still interested in getting your improvements upstreamed?

It looks like there are a whole bunch of things this driver does better than current upstream, like advanced rumble, battery reports, report fixups etc.

And it'd be really nice to have that work just out of the box on Linux rather than having to install a dkms driver manually.

I suspect the best way of getting these changes accepted is to do it really incrementally and add to the existing hid-microsoft driver a feature at a time.

A good starting point might be the battery reporting? So take the existing battery parsing functionality, extract just the minimally necessary functions and port them over to https://github.com/torvalds/linux/blob/master/drivers/hid/hid-microsoft.c

https://github.com/torvalds/linux/blob/master/drivers/hid/hid-sony.c looks helpful as a reference for how to wire it all up.

That should result in a small patch that we could send upstream and hopefully merged :)

It would be so nice to see this upstreamed :slightly_smiling_face:

If this is a lot of work, maybe you could do bounty for this or do a crowdfounding campain like @flibitijibibo did for adding Nintendo's USB GameCube controller support in SDL2.

I'm sure you could get some traction on this.

The point is, that I am not too eager to stuff the whole driver into hid-microsoft, this is simply not the right (or at least a not clever) way to go in my eyes.

The reson is that this driver is still in progress, Elite support and other devices and interfaces will follow - all this will more and more blow up hid-microsoft.

It wouldn't be fun to maintain this thing then.

If someone with decisional power would tell me that we can leave hid-xpadneo in one peace, I woud immediately do it.

@atar-axis did you give up on this?

Not really, but there is still so much to do before it is worth the efforts. But you are right, let me reopen it ;)

I don't know the process, but it doesn't seem to be very straightforward. I'm sorry I can't really help, as I don't really know anything about kernels, drivers, or mainlining process.

Anyway, so that everyone can see, what does it need to be done that is blocking this issue?

There is the staging tree, you know.

Hey! I wrote the Xbox One wired controller support in the xpad driver a few years ago. If there's anything I could do to help you here I'd be happy to try! Getting patches into the Linux kernel is a huge headache. I wound up exchanging emails with someone at Valve who helped get my patch landed.

I think it may be worth porting single features that this has over upstream hid-microsoft.c directly to that latter driver. One I can think of would be to support trigger rumble upstream so we could remove that from this driver and use upstream instead. That way, trigger rumble could become actually supported in games. And kernel upstream surely has better ideas how to integrate it into the FF API - misusing direction doesn't feel like the proper ultimate way to do it.

@luser Do you know of any discussion enhancing the FF API?

I agree with @kakra It would be nice to upstream small features like....

select and guide button not working on elite 2 controller. or battery monitoring feature.

I think the select and guide button are not reported properly using the hid-generic so we need at least a few quirks to have a good out the box experience.

btw thank for this great project :)

The XBE2 controller still has issues according to reports in this project. So we'd need to fix those first before the feature could be considered for porting to upstream.

I don't know... Simply mainlining battery or things like these... In my experience (Xbox One S controller, last revision), there are cases that the controller will simply not work at all with xpad. For example, to use it with Kodi I had to compile Kodi with xpadneo, because with the default xpad driver only the select button would work, and incorrectly mapped.

The pre-requisite Bluetooth patch has landed in bluetooth-next, and work on upstream can proceed.

I think the best course of action would be to clean up the upstream to be able to bring in (stable) functionality that's available here piecemeal, and once that's done, rebase the driver in this repo to some sort of a staging ground for the upstream driver.

The first step would be to split up the xbox controller support from the hid-microsoft.c source into a separate driver. The new PS5 controller support is also using a separate file for that, rather than adding more into hid-sony.c. Then each new functionality or device ID can be a separate patch.

@atar-axis you have my email address, feel free to CC: me on patches you want to send upstream, or branches you'd like to me to inspect on github, I'm eager to have all this work reach upstream so anyone can use those devices. I also have a bunch of XBox One and Series X controllers here for testing should that be needed.

@hadess atar-axis is currently not maintaining the driver, I'm doing it and I have write access to the repository. It's nice to see the L2CAP patch suggested for upstream. Thanks for the heads-up.

I'm also maintaining a rebase-branch to integrate the driver directly into the kernel so it can be used built-in: https://github.com/kakra/linux/pull/11

But that doesn't touch or clean the other drivers at all (except removing some device IDs).

@medusalix is also working on a kernel driver to support the GIP protocol of the controller (using the dongle), so we may wait some more time and combine efforts. Also, I want to add support for profile programming of the XBE2 controller but I still need to reverse engineer the protocol for that: It allows remapping buttons (even to keyboard events) and changing axes scale and response curves, and my current believe is that this is implemented in hardware.

I'm also maintaining a rebase-branch to integrate the driver directly into the kernel so it can be used built-in: kakra/linux#11

Do you want me to comment there on how the support should be brought in?

Do you want me to comment there on how the support should be brought in?

I'm not sure if the PR is the right place (because I'm dismissing those with the next kernel LTS) but we could start there because the review tools would be a good way to start working on that. Are you familiar with getting changes upstreamed?

Are you familiar with getting changes upstreamed?

I've written a few upstream drivers.

@hadess Cool, sounds like a plan then.

Sorry for the noise. I have an elite 2 controller and I am a Gentoo user and I know how to compile the kernel.

I can test patches if you need testers.

I would like to see this driver in mainline.

Thanks for your work.

@mercuriete For Gentoo, download https://github.com/kakra/linux/pull/11.patch and drop the file into /etc/portage/patches/sys-kernel/gentoo-sources/9300_xpadneo.patch (simply create missing directories, or if you're using a different kernel, use an appropriate named directory). Then re-emerge gentoo-sources. If you're later seeing problems during merge, you may need to re-download the file as I will update the PR regularly to match 5.10 LTS (you can subscribe the PR). Run make menuconfig to select xpadneo either built-in or as a module.

With this patch in place, you can remove the ERTM fix, udev rules (mostly) and modalias hints.

This is actually how I am using this in Gentoo so I don't have to re-install xpadneo after each kernel update.

BTW: This is for kernel 5.10 which may still be keyworded in Gentoo. I'm pretty sure you know how to properly get that kernel version for Gentoo.

@kakra TLDR; WORKS_FOR_ME

I will update this comment when I finish more tests

1. the patch was copied today 2021-01-27
2. the patch was applied on top of sys-kernel/gentoo-sources-5.10.10
3. my controller is a Elite Wireless Controller Series 2

tested on:

uname -a
Linux desktop 5.10.10-gentoo #1 SMP PREEMPT Wed Jan 27 10:58:11 WET 2021 x86_64 AMD Ryzen 7 2700X Eight-Core Processor AuthenticAMD GNU/Linux

my kernel config is:

cat .config | grep XPADNEO
CONFIG_HID_XPADNEO=y

bluetooth dongle (my dongle is reported to be buggy but it works for me):

lsusb
Bus 001 Device 005: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

features that works:

• [x] Pairing without disabling ERTM
• [x] Buttons and axis
• [x] Vibration
• [x] Battery reporting

features that doesn't seems to work:

weird behaviours:

• [x] when you open on KDE joystik KCM (systemsettings) there are a huge input lag like seconds of delay when using the axis. But the input lag is perfect on games. It seems this bug is known and not a problem from this driver.

PS: @kakra thank you very much for explaining how to patch the kernel on gentoo. You are a very kind person. I hope you succeed making this driver mainline.

Updated: Battery works, Joystik KCM is known to be buggy.