[PATCH 0/1] Input: xpad - add disable_xboxone module parameter

[PATCH 0/1] Input: xpad - add disable_xboxone module parameter

[Apoorv Parle]

Hi,

This patch adds a `disable_xboxone` module parameter to the xpad driver,
allowing users to prevent xpad from binding to Xbox One and Series X|S
devices (XTYPE_XBOXONE). This is especially useful for users who wish to
use the out-of-tree `xone` driver (https://github.com/dlundqvist/xone) .

Currently, there is no in-tree driver that supports Xbox wireless dongles;
the only option is the out-of-tree `xone` project which implements the GIP
protocol. The `xone` project itself, or similar functionality  cannot be
easily upstreamed due to the unclear legality of redistributing the
required Microsoft firmware. This patch lets users avoid device conflicts
and run both drivers side by side, without having to patch or fork xpad
(eg: https://github.com/medusalix/xpad-noone) for each kernel update.

Tested on kernel version 6.14.0 with both legacy Xbox 360 controllers
and a Microsoft Xbox Wireless Adapter Dongle + Xbox Controller Model 1914

Thanks for your consideration.

Best,
Apoorv Parle

Apoorv Parle (1):
  Input: xpad - add disable_xboxone module parameter

 drivers/input/joystick/xpad.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

-- 
2.48.1

[PATCH 1/1] Input: xpad - add disable_xboxone module parameter

[Apoorv Parle]

This parameter skips probing for XTYPE_XBOXONE devices, allowing
out-of-tree drivers like xone to handle newer Xbox controllers
without conflicts.

Signed-off-by: Apoorv Parle <apparle@gmail.com>
---
 drivers/input/joystick/xpad.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 57a5ff3d1992..5bab5c2250d2 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -121,6 +121,10 @@ static bool auto_poweroff = true;
 module_param(auto_poweroff, bool, S_IWUSR | S_IRUGO);
 MODULE_PARM_DESC(auto_poweroff, "Power off wireless controllers on suspend");
 
+static bool disable_xboxone;
+module_param(disable_xboxone, bool, 0644);
+MODULE_PARM_DESC(disable_xboxone, "Disable all Xbox One devices (XTYPE_XBOXONE)");
+
 static const struct xpad_device {
 	u16 idVendor;
 	u16 idProduct;
@@ -2089,6 +2093,14 @@ static int xpad_probe(struct usb_interface *intf, const struct usb_device_id *id
 			xpad->mapping |= MAP_STICKS_TO_NULL;
 	}
 
+	if (xpad->xtype == XTYPE_XBOXONE && disable_xboxone) {
+		/*
+		 * Disable XTYPE_XBOXONE based on module parameter.
+		 */
+		error = -ENODEV;
+		goto err_free_in_urb;
+	}
+
 	if (xpad->xtype == XTYPE_XBOXONE &&
 	    intf->cur_altsetting->desc.bInterfaceNumber != GIP_WIRED_INTF_DATA) {
 		/*
-- 
2.48.1

Re: [PATCH 0/1] Input: xpad - add disable_xboxone module parameter

[Dmitry Torokhov]

Hi Apoorv,

On Sat, May 17, 2025 at 03:50:44AM -0700, Apoorv Parle wrote:
> Hi,
> 
> This patch adds a `disable_xboxone` module parameter to the xpad driver,
> allowing users to prevent xpad from binding to Xbox One and Series X|S
> devices (XTYPE_XBOXONE). This is especially useful for users who wish to
> use the out-of-tree `xone` driver (https://github.com/dlundqvist/xone) .
> 
> Currently, there is no in-tree driver that supports Xbox wireless dongles;
> the only option is the out-of-tree `xone` project which implements the GIP
> protocol. The `xone` project itself, or similar functionality  cannot be
> easily upstreamed due to the unclear legality of redistributing the
> required Microsoft firmware. This patch lets users avoid device conflicts
> and run both drivers side by side, without having to patch or fork xpad
> (eg: https://github.com/medusalix/xpad-noone) for each kernel update.

I believe this can be achieved from userspace by unbinding the original
xbox driver and binding the alternative driver via sysfs, no kernel
changes needed.

Thanks.

-- 
Dmitry

Re: [PATCH 0/1] Input: xpad - add disable_xboxone module parameter

[Apoorv Parle]

The goal is to not blacklist the xpad driver completely, because I
still need that driver for other controllers (older Xbox 360
controller or 3rd party controllers) when using multiple controllers
(couch multiplayer) on the same machine.

Today I'm forced to blacklist xpad altogether to get xone up because
they conflict on the device IDs, and then I can only use 1 controller,
not both.
Or I have to create a copy of xpad with Xbox-One device IDs stripped
out (i.e. xpad-noone) to keep both drivers active side-by-side, so my
new XboxOne can use xone and my old Xbox 360 can use the xpad driver.
This patch is trying to make that seamless. And it'll have the added
benefit of making distro packaging easier as xpad can just stay
upstream with no separate builds needed, and xone driver can be a
non-free opt-in installation with this module param enabled.

On Mon, May 19, 2025 at 9:32 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> Hi Apoorv,
>
> On Sat, May 17, 2025 at 03:50:44AM -0700, Apoorv Parle wrote:
> > Hi,
> >
> > This patch adds a `disable_xboxone` module parameter to the xpad driver,
> > allowing users to prevent xpad from binding to Xbox One and Series X|S
> > devices (XTYPE_XBOXONE). This is especially useful for users who wish to
> > use the out-of-tree `xone` driver (https://github.com/dlundqvist/xone) .
> >
> > Currently, there is no in-tree driver that supports Xbox wireless dongles;
> > the only option is the out-of-tree `xone` project which implements the GIP
> > protocol. The `xone` project itself, or similar functionality  cannot be
> > easily upstreamed due to the unclear legality of redistributing the
> > required Microsoft firmware. This patch lets users avoid device conflicts
> > and run both drivers side by side, without having to patch or fork xpad
> > (eg: https://github.com/medusalix/xpad-noone) for each kernel update.
>
> I believe this can be achieved from userspace by unbinding the original
> xbox driver and binding the alternative driver via sysfs, no kernel
> changes needed.
>
> Thanks.
>
> --
> Dmitry

Re: [PATCH 0/1] Input: xpad - add disable_xboxone module parameter

[Dmitry Torokhov]

On Mon, May 19, 2025 at 01:30:13PM -0700, Apoorv Parle wrote:
> The goal is to not blacklist the xpad driver completely, because I still
> need that driver for other controllers (older Xbox 360 controller or 3rd
> party controllers) when using multiple controllers (couch multiplayer) on
> the same machine.
> 
> Today I'm forced to blacklist xpad altogether to get xone up because they
> conflict on the device IDs, and then I can only use 1 controller, not both.
> Or I have to create a copy of xpad with Xbox-One device IDs stripped out
> (i.e. xpad-noone) to keep both drivers active side-by-side, so my new
> XboxOne can use xone and my old Xbox 360 can use the xpad driver.
> This patch is trying to make that seamless. And it'll have the added
> benefit of making distro packaging easier as xpad can just stay upstream
> with no separate builds needed, and xone driver can be a non-free opt-in
> installation with this module param enabled.

I understand. However you can unbind and bind individual devices to
individual drivers via sysfs by writing into
/sys/bus/usb/drivers/{xpad|xone}/{un}bind.

Thanks.

-- 
Dmitry

Re: [PATCH 0/1] Input: xpad - add disable_xboxone module parameter

[Apoorv Parle]

Ah, yes, that's possible. But it's too hard to generally use -
requires manual command line intervention each time the xbox dongle is
plugged-in and/or computer reboots.There's no easy way to robustly
automate this especially for layperson linux gamers.
A stripped-down and hand-compiled version of xpad is at least fully
automated, but only until the linux kernel is updated by the distro.

On Mon, May 19, 2025 at 2:36 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> I understand. However you can unbind and bind individual devices to
> individual drivers via sysfs by writing into
> /sys/bus/usb/drivers/{xpad|xone}/{un}bind.
>
> Thanks.
>
> --
> Dmitry

Re: [PATCH 0/1] Input: xpad - add disable_xboxone module parameter

[Apoorv Parle]

From what I've read on udev rules so far, I'm not sure if there's a
clean deterministic way of unbinding one driver and binding it to
another.
As I understand, I'll have to write a script to run for either the
"add" action or the "bind" action. The "add" script runs asynchronous
to kernel's binding, so it could happen before or after xpad binding
is done; and even if I unbind it, kernel can re-bind it again while
scanning the USB bus, which again creates a race with the script. If I
use the "bind" action instead of "add" action, the script can recurse
depending on timing of kernel's attempt to rebind. I tried to look for
similar examples but couldn't find any -- just a few very high cpu
usage bugs due to similar recursion.
Other similar scenarios (like graphics drivers) that I tried to find,
just blacklist whole kernel modules or used some module param.

Though I'll admit, my knowledge of udev rules is somewhat limited.


On Mon, May 19, 2025 at 11:23 PM A. Bosch <progandy@progandy.de> wrote:
>
> Hi,
>
> could you not create udev rules to perform these actions?
>
> - Andreas
>
>
> Am 20. Mai 2025 06:04:36 MESZ schrieb Apoorv Parle <apparle@gmail.com>:
>>
>> Ah, yes, that's possible. But it's too hard to generally use -
>> requires manual command line intervention each time the xbox dongle is
>> plugged-in and/or computer reboots.There's no easy way to robustly
>> automate this especially for layperson linux gamers.
>> A stripped-down and hand-compiled version of xpad is at least fully
>> automated, but only until the linux kernel is updated by the distro.
>>
>> On Mon, May 19, 2025 at 2:36 PM Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>>>
>>>
>>>  I understand. However you can unbind and bind individual devices to
>>>  individual drivers via sysfs by writing into
>>>  /sys/bus/usb/drivers/{xpad|xone}/{un}bind.
>>>
>>>  Thanks.
>>>
>>>  --
>>>  Dmitry
>>
>>

Re: [PATCH 0/1] Input: xpad - add disable_xboxone module parameter

[Apoorv Parle]

Any thoughts on considering this patch?

On Wed, May 21, 2025 at 2:45 PM Apoorv Parle <apparle@gmail.com> wrote:
>
> From what I've read on udev rules so far, I'm not sure if there's a
> clean deterministic way of unbinding one driver and binding it to
> another.
> As I understand, I'll have to write a script to run for either the
> "add" action or the "bind" action. The "add" script runs asynchronous
> to kernel's binding, so it could happen before or after xpad binding
> is done; and even if I unbind it, kernel can re-bind it again while
> scanning the USB bus, which again creates a race with the script. If I
> use the "bind" action instead of "add" action, the script can recurse
> depending on timing of kernel's attempt to rebind. I tried to look for
> similar examples but couldn't find any -- just a few very high cpu
> usage bugs due to similar recursion.
> Other similar scenarios (like graphics drivers) that I tried to find,
> just blacklist whole kernel modules or used some module param.
>
> Though I'll admit, my knowledge of udev rules is somewhat limited.
>
>
> On Mon, May 19, 2025 at 11:23 PM A. Bosch <progandy@progandy.de> wrote:
> >
> > Hi,
> >
> > could you not create udev rules to perform these actions?
> >
> > - Andreas
> >
> >
> > Am 20. Mai 2025 06:04:36 MESZ schrieb Apoorv Parle <apparle@gmail.com>:
> >>
> >> Ah, yes, that's possible. But it's too hard to generally use -
> >> requires manual command line intervention each time the xbox dongle is
> >> plugged-in and/or computer reboots.There's no easy way to robustly
> >> automate this especially for layperson linux gamers.
> >> A stripped-down and hand-compiled version of xpad is at least fully
> >> automated, but only until the linux kernel is updated by the distro.
> >>
> >> On Mon, May 19, 2025 at 2:36 PM Dmitry Torokhov
> >> <dmitry.torokhov@gmail.com> wrote:
> >>>
> >>>
> >>>  I understand. However you can unbind and bind individual devices to
> >>>  individual drivers via sysfs by writing into
> >>>  /sys/bus/usb/drivers/{xpad|xone}/{un}bind.
> >>>
> >>>  Thanks.
> >>>
> >>>  --
> >>>  Dmitry
> >>
> >>