Add paddles support for the Elite Series 2 firmware versions < 5.x

[charlesmunger]

Tested with firmware 4.7 and evtest. Works in Steam Input when no profile is selected on the controller. Input event codes are the same as what xpad reports for paddles, so most controller profiles should work in both wired and wireless modes.

[Entropy512]

As architected, this is not extendable without significant rework to support other Elite controllers such as the original Elite

I've added a rework of your commit that is tested to work with the original Elite at https://github.com/Entropy512/xone/commits/paddles/

You can either cherry pick it and add to your PR, or I'll PR a combo of your patch and my rework.

[Riven-Spell]

Adjusted the existing xone-dkms-git PKGBUILD for Arch-based users who'd like to beta test use this work early; credit to Michał Kopeć michal@nozomi.space

_pkgname=xone
pkgname=xone-dkms-git
pkgver=makepkg.53964a4
pkgrel=1
pkgdesc='Modern Linux driver for Xbox One and Xbox Series X|S controllers'
arch=('x86_64')
url='https://github.com/Entropy512/xone'
license=('GPL2')
depends=('dkms'
		 'xone-dongle-firmware')
makedepends=('git')
conflicts=('xone-dkms'
		   'xow')
provides=('xone-dkms')
source=("git+https://github.com/Entropy512/xone.git#branch=paddles")
sha256sums=('SKIP')

pkgver() {
  cd "$srcdir/$_pkgname"
  # git describe --long --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'
  echo "$(git branch --show-current).$(git rev-parse --short HEAD)"
}

package() {
  cd "${srcdir}/${_pkgname}"

  find . -type f \( -name 'dkms.conf' -o -name '*.c' \) -exec sed -i "s/#VERSION#/$pkgver/" {} +
  echo 'ccflags-y += -DDEBUG' >> "Kbuild"

  echo "* Copying module into /usr/src..."
  install -dm755 "${pkgdir}/usr/src/${_pkgname}-${pkgver}"
  cp -r "${srcdir}/$_pkgname"/* "${pkgdir}/usr/src/${_pkgname}-${pkgver}"

  echo "* Blacklisting xpad module..."
  install -D -m 644 install/modprobe.conf "${pkgdir}/etc/modprobe.d/xone-blacklist.conf"
}

[Entropy512]

Note that it looks like it's possible to support newer Elite 2 firmwares, but I have no way to test those configurations.

If there's someone with a newer-firmware Elite 2 that wants to try it, I can take a crack at adding it based on xpad's setup.

[Riven-Spell]

I actually do have an Elite 2. I can pop over to Windows and pull the latest firmware and act as a guinea pig. No skin off my back, paddles were never bindable via steam input for me.

[Riven-Spell]

I actually do have an Elite 2. I can pop over to Windows and pull the latest firmware and act as a guinea pig. No skin off my back, paddles were never bindable via steam input for me.

https://github.com/Riven-Spell/xone/tree/paddles

tried my hand at porting it, but, not real sure where to head from here.

[Entropy512]

Yeah the latest Elite firmware seems to be a little more challenging:

An extra init packet needs to be sent: https://github.com/paroj/xpad/blob/master/xpad.c#L612

The equivalent of the already-implemented init packet at https://github.com/paroj/xpad/blob/master/xpad.c#L602 is in bus/protocol.c for xone - https://github.com/medusalix/xone/blob/master/bus/protocol.c#L420 - so something like gip_set_extra_input() would need to be implemented

Then the extra input is in a different packet for the latest Elite2 firmware - https://github.com/paroj/xpad/blob/master/xpad.c#L1090 (GIP_CMD_FIRMWARE is a bit of an odd name for this - definition reuse???) - implementing the equivalent to this appears to be necessary in gip_dispatch_pkt + similar structure to the functions called from there (gip_handle_pkt_input and so on)

I'll take a look at your stuff and try and take a poke at it this afternoon.

Edit: Heh, looks like you already figured that out. Will take a look later. Personally I think they recycled the GIP_CMD_FIRMWARE line so it should probably be called gip_handle_pkt_extinput or something like that.

I STRONGLY disagree with xpad's approach of not allowing a profile to be applied:

1. If two reports come from a single button, most software will just ignore the report that it's not interested in. It might mess up button-assignment approaches though in some games, so maybe this needs to somehow be an option
2. There are lots of scenarios where a profile is applied but the paddles are not mapped in the controller, with the intent being to map them host-side. This is EXACTLY my use case, since one of the primary reasons I like to use an Elite controller is to disable the thumbsticks completely and use the lower L/R paddles instead, but also be able to map the upper L/R paddles separately from the RB/LB buttons in some games/applications. People also uses profiles for other things like stick sensitivity mapping, brightness, etc.

I'll see if I still have it around somewhere, but I added a bit of code to print the entire packet in hex, which let me figure out some pesky off-by-one errors. :)

At the current point - now that you've implemented Riven-Spell@cd596fc are you seeing extrainput packets come in? Or are they still not coming in? Maybe the init packet needs to be sent earlier? xpad sends that init packet to Elite2 controllers no matter what firmware revision they are. I'll have to look later, but is the VID/PID set inside the hardware member of the gip_client struct passed to gip_gamepad_probe? That's where GIP_CMD_POWER is sent.

[Riven-Spell]

I am not seeing the extra input packets come in, unfortunately. I think there might be something wrong with the init packet I sent, or something else along those lines. I have yet to fire both xone and native up under wireshark and go through with a fine-tooth comb.

[medusalix]

Yeah the latest Elite firmware seems to be a little more challenging:

An extra init packet needs to be sent: paroj/xpad@master/xpad.c#L612

@Entropy512 I strongly suspect that Microsoft doesn't want to support the paddles as additional buttons on Windows. That's why they don't hesitate to change the offset in the input packet on every new firmware version.
That also explains why the Series 2 Elite Controller requires an extra (client-specific) packet to be sent to activate them on newer firmwares: The actual paddle input is really only used by the Xbox Accessories App. The paddles are meant to be hardware remapped via profiles to arbitrary keys, which is supported by the Elite 2.

I believe hardware-mapped paddles should already work for xone, so I'd suggest that we build something similar to the Xbox Accessories App for Linux instead. That way we can avoid breaking the paddle functionality for every new firmware.

[Riven-Spell]

@Entropy512 I strongly suspect that Microsoft doesn't want to support the paddles as additional buttons on Windows.

Actually wouldn't be surprised if it was just to screw with us.

I believe hardware-mapped paddles should already work for xone, so I'd suggest that we build something similar to the Xbox Accessories App for Linux instead. That way we can avoid breaking the paddle functionality for every new firmware.

I'd much prefer the paddles were supported as a button. IMO, it's quite clunky/bad UX to have mapping to other controller buttons be the only option. It could be a fallback option, with paddle support being a build flag or something.

Maybe the init packet needs to be sent earlier? xpad sends that init packet to Elite2 controllers no matter what firmware revision they are. I'll have to look later, but is the VID/PID set inside the hardware member of the gip_client struct passed to gip_gamepad_probe? That's where GIP_CMD_POWER is sent.

Not sure. I'll take a look maybe late tonight and see what I can do.

[Riven-Spell]

I'd much prefer the paddles were supported as a button.

I should clarify. I bought the controller coming from the steam deck, and was mostly hoping I could use the paddles under steam input.