xpadneo

[Xdavius]

Please confirm there isn't an existing package request

• [X] I have searched through package requests

Homepage

https://github.com/atar-axis/xpadneo

Maintainer

• [ ] Would you like to be the maintainer for this package?

Why should this be included in the repository?

The package provide xpadneo driver for Xbox Series S|X gamepad, turtle beach and pro elite controller, for USB and Bluetooth.

Are we allowed to redistribute it?

GNU v3

What kind of user will use this package, and how many users do you think will use this package?

Linux gaming users using one of the more recent Xbox gamepad or elite must have this driver. For now, lot of older controller are in the market but they will be replaced.

This driver doesn't conflict with xone, who provides the driver for the Xbox dongle.

Link to source archive file

https://github.com/atar-axis/xpadneo/archive/refs/tags/v0.9.6.tar.gz

[malfisya]

Same request https://github.com/getsolus/packages/issues/1419 . Do note that Solus doesn't support DKMS.

[Xdavius]

Hi.

The issue you mentioned was closed. That's why I created an other.

In my opinion, not providing dkms is a mistake because it's the standard for deployment of 3rd party modules. And it permit also the usage of custom kernels. I understand also the point of view that prebuilt modules ensure they are working for a kernel. And it also permit signing them directly without dealing with mok.

As open suse, it may be optional for users to deal with.

But, that wasn't the objective talking to this now.

By the way, xpadneo can just be built and packaged the same way you provide the others drivers.

xpadneo is stable now, and needed for the controllers mentioned above.

It's one of the things that block to recommend Solus as a daily driver for gaming, because new players will by new controllers, and want to have the latest features. Also, if someone have an Xbox Series, il won't by an older controller to play on his linux PC (And will play on windows ^^)

So, I really hope you will consider adding this package. It will be a Big step ahead for Linux gaming/home linux computing for Solus.

Thank you for reading.

[TraceyC77]

Hi,

In the closed request, HarveyDevel verified that his XBox X/S Controller can connect over Bluetooth without this software. yusi1 verified this as well.

Are there controllers that are verified to not currently work over bluetooth that this would support?

Edit: I'm confirming what @malfisya said about DKMS. We do not support it. The package can be built without it.

[Xdavius]

Hi @TraceyC77

I can confirm that some controllers doesn't work without this module.

My friend Cardiacman13 is impacted, and other members of our group. It's seems depending on the model revision/firmware of the gamepad.

Factually, for all Elite controller it is necessary. For S/X, and sometimes for Xbox one too.

Mine work without it, but some people can have lots of bug (recognized but inverted input, not recognized at all, pairing loose) and xpadneo solve all theses issues.

It's seems to be also needed for the turtle beach (unofficial Xbox controller) one.

I wasn't able to define a pattern to say : this one works without, this one works with it. We are helping people case by case.

No problem for not supporting dkms. I respect your choice. If you can bundle it directly as a module, no problem.

I named it -dkms because it is the official name.

I have people who can test a package.

Thanks you.

[infinitymdm]

A long time ago we discussed bundling xpadneo-noone into xone as it enabled support for xbox controllers via Bluetooth. However, testing at that time (with a series S/X controller) showed basically no benefit vs. without xpadneo.

As it seems like there is extra hardware enablement to be gained by moving forward with this, I'd suggest bundling xpadneo into xone for a "one Xbox hardware support package to rule them all" approach. Otherwise I believe xpadneo has some conflicts with xone.

If I have some time this week, I'll look into building and testing a bundled package. If it goes ok I'd be willing to maintain this as part of xone maintainership.

[Xdavius]

Hi @infinitymdm

I think this is not a good idea. In the case you've got 2 gamepad and want to play 2 players game, If you have one with dongle and an other incompatible with xpadneo, you will go to an issue and have to blacklist it manually. It's not user friendly even if I understand your idea.

I suggest separated packages to avoid any possibility of issues and keep it KISS.

Regards.

[infinitymdm]

In the case you've got 2 gamepad and want to play 2 players game, If you have one with dongle and an other incompatible with xpadneo, you will go to an issue and have to blacklist it manually.

This is more or less the case I'm trying to avoid, actually. If you connect a controller via the Xbox dongle, it should just work (using xone under the hood). Likewise, if you connect via Bluetooth, it should just work (using xpadneo under the hood). I agree that having to blacklist hardware manually isn't user friendly, and so I'm trying to avoid that ever happening.

However, I also don't want users to be confused if they try to install xone to support their shiny new Xbox dongle, and find out that they have to uninstall xpadneo because it has conflicts with xone. I might be wrong there though - perhaps they don't conflict anymore, in which case there's no need for this bundling at all. I'll look into it.

[infinitymdm]

After discussing with folks on the xpadneo Discord, it looks like the only potential conflict between the current versions of xone and xpadneo has to do with using both the Microsoft GIP dongle and bluetooth connections at the same time. No one seems sure how connections are prioritized if you're trying to pair with a computer while the dongle is connected - meaning if you want to connect via bluetooth, you might have to unplug the dongle, pair, and plug the dongle back in. You may also have to re-pair devices to the dongle, and no one seems sure what happens If you have a device paired one way and you try to pair it using the other method.

This isn't ideal, but I don't think it's a big enough user experience problem that the packages should conflict with one another. So keeping xpadneo a separate package from xone should be fine, I think. I'd like to look into some of the unknowns here and figure out what sort of behavior we can expect, so that we know how to diagnose people's problems when they inevitably arise.