[5.10] Track xpadneo as in-kernel driver

[kakra]

Export patch series: https://github.com/kakra/linux/pull/11.patch

[hadess]

A couple of comments on this patchset:

• pick up the L2CAP patch from upstream so it gets automatically discarded when you rebase
• I don't think that xpadneo will be accepted as a name upstream, hid-xbox-one, or hid-xbox-one-wireless, or hid-xbox-one-bt or any combination of hid-, xbox, one, wireless, and bt. Might want to ask on linux-input@ although you can always submit with the name you like better, and changing the name in a v2 would be pretty straight forward.
• patches like "Added hid-xpadneo to Makefile" and "Added hid-xpadneo to Kconfig (hid)" should be combined with the driver itself, such that any of the patches can be applied in succession, and always compile correctly (git rebase -x "make modules" origin/master is a good way to run the build for each individual patch
• dumping 1200 lines of code for the driver isn't going to get accepted or reviewed, it's difficult to see what regressions this could bring, or what the changes are compared to the original driver. I would recommend having a hid: Move XBox One wireless support to new driver commit, which adds a skeleton driver, with Kconfig and Makefile changes. This driver would be the exact same code as the one currently in hid-microsoft.c, just code movement. From then, you can start adding support for individual features, that is, moving features from hid-xpadneo to the new hid-xbox-something driver, like force feedback, battery support, or support for individual devices. It might be long, but that means that each new functionality will be reviewable by itself, in smaller patches. Easier to read six 200-line patches than a 1200-line patch.

You also don't need to add all of the functionality that's in hid-xpadneo in one go. You could start with the driver split and one functionality you think is useful (maybe support for batteries, or more devices, depending on what's easiest), and go from there.

[kakra]

pick up the L2CAP patch from upstream so it gets automatically discarded when you rebase

Makes sense. But when that happens, I would just drop this anyways. I don't feel like upstreaming before this commit is in.

I don't think that xpadneo will be accepted as a name upstream, hid-xbox-one, or hid-xbox-one-wireless, or hid-xbox-one-bt or any combination of hid-, xbox, one, wireless, and bt. Might want to ask on linux-input@ although you can always submit with the name you like better, and changing the name in a v2 would be pretty straight forward.

It's called like this upstream, so I prefer sticking to that until we are finally ready for kernel upstreaming. The core driver is already called hid-xpadneo, the include file is called just xpadneo.h for now - this will be fixed later, I'm in the process of splitting the driver because it's becoming quite big. I think we could go with hid-xboxone-bt, let's not put too many dashes.

patches like "Added hid-xpadneo to Makefile" and "Added hid-xpadneo to Kconfig (hid)" should be combined with the driver itself, such that any of the patches can be applied in succession, and always compile correctly (git rebase -x "make modules" origin/master is a good way to run the build for each individual patch

These are currently separate commits because I'm updating them independent from each other when getting updates from the xpadneo project or adding support for new hardware. In a final upstream effort, I'd combine them.

dumping 1200 lines of code for the driver isn't going to get accepted or reviewed, it's difficult to see what regressions this could bring, or what the changes are compared to the original driver.

Yeah, that's true. But there's a plan already (in my mind).

I would recommend having a hid: Move XBox One wireless support to new driver commit, which adds a skeleton driver, with Kconfig and Makefile changes. This driver would be the exact same code as the one currently in hid-microsoft.c, just code movement.

Good idea to start with, it supports what I was planning.

From then, you can start adding support for individual features, that is, moving features from hid-xpadneo to the new hid-xbox-something driver, like force feedback, battery support, or support for individual devices. It might be long, but that means that each new functionality will be reviewable by itself, in smaller patches. Easier to read six 200-line patches than a 1200-line patch.

The plan was to move individual fixes and features over to hid-microsoft step by step (or rather, to our own "skeleton copy" as you suggested). I'd probably start with the rumble work-around first. I've not decided how to handle our HID report fixups and SDL work-arounds. I consider those quite hacky, we probably should not ship hacky stuff with the kernel as it would break SDL2 in the wild. What do you think?

You also don't need to add all of the functionality that's in hid-xpadneo in one go. You could start with the driver split and one functionality you think is useful (maybe support for batteries, or more devices, depending on what's easiest), and go from there.

See above: I'd start with upstreaming the rumble crash fixes. I'd probably re-do battery support to match hidpp (Logitech support) more closely. I've already started with that but stopped at the point where we are now.

We already registered a Github project https://github.com/xpadneo where we could centralize all upstreaming efforts, and move this project over as a starting point (in a different form aka "as a kernel branch" - maybe? -, because @atar-axis wants to keep the original xpadneo in place for future CVs).

[orbea]

@kakra What's the status on these patches with newer kernels? It doesn't apply with 5.11 or 5.12 kernels.

[kakra]

I'm only concerned about the latest LTS kernel here. But actually, there should only be simple to resolve conflicts.

[kakra]

But something is fishy about the base version for this PR... I'll check that later.

[kakra]

@orbea Please retry, I pushed the missing commits to the base branch and force pushed the xpadneo commits again.

[orbea]

@kakra I retried with 5.12.6 and it works after omitting the first patch which is already applied: [PATCH 1/7] Bluetooth: L2CAP: Try harder to accept device not knowing. Thanks!

[kakra]

Closing in favor of 5.15 LTS