Adds support for the X-Box Adaptive Controller, which is protocol
compatible with the XTYPE_XBOXONE support in the driver with two deltas:
- The X-Box button sets 0x02 as its activation ID, where others set
0x01
- The controller has an additional "Layer" button with 4 active states,
which this change maps to an Axis control with 4 possible values
Signed-off-by: Nate Yocom <[email protected]>
---
v2: Fix warning Reported-by: kernel test robot <[email protected]>
drivers/input/joystick/xpad.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 18190b529bca..b411bfb9a6b8 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -80,6 +80,7 @@
#define MAP_TRIGGERS_TO_BUTTONS (1 << 1)
#define MAP_STICKS_TO_NULL (1 << 2)
#define MAP_SELECT_BUTTON (1 << 3)
+#define MAP_LAYER_BUTTON (1 << 4)
#define DANCEPAD_MAP_CONFIG (MAP_DPAD_TO_BUTTONS | \
MAP_TRIGGERS_TO_BUTTONS | MAP_STICKS_TO_NULL)
@@ -131,6 +132,7 @@ static const struct xpad_device {
{ 0x045e, 0x02e3, "Microsoft X-Box One Elite pad", 0, XTYPE_XBOXONE },
{ 0x045e, 0x02ea, "Microsoft X-Box One S pad", 0, XTYPE_XBOXONE },
{ 0x045e, 0x0719, "Xbox 360 Wireless Receiver", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W },
+ { 0x045e, 0x0b0a, "Microsoft X-Box Adaptive Controller", MAP_LAYER_BUTTON, XTYPE_XBOXONE },
{ 0x045e, 0x0b12, "Microsoft Xbox Series S|X Controller", MAP_SELECT_BUTTON, XTYPE_XBOXONE },
{ 0x046d, 0xc21d, "Logitech Gamepad F310", 0, XTYPE_XBOX360 },
{ 0x046d, 0xc21e, "Logitech Gamepad F510", 0, XTYPE_XBOX360 },
@@ -857,7 +859,17 @@ static void xpadone_process_packet(struct usb_xpad *xpad, u16 cmd, unsigned char
if (data[1] == 0x30)
xpadone_ack_mode_report(xpad, data[2]);
- input_report_key(dev, BTN_MODE, data[4] & 0x01);
+ /*
+ * X-Box Adaptive controller sets 0x02 when x-box button is pressed,
+ * we could probably condense into just data[4] != 0, but explicitly
+ * checking here ensures no regression if other devices set other bits.
+ */
+ if (le16_to_cpu(xpad->dev->id.vendor) == 0x045e &&
+ le16_to_cpu(xpad->dev->id.product) == 0x0b0a)
+ input_report_key(dev, BTN_MODE, data[4] & 0x02);
+ else
+ input_report_key(dev, BTN_MODE, data[4] & 0x01);
+
input_sync(dev);
return;
}
@@ -926,6 +938,10 @@ static void xpadone_process_packet(struct usb_xpad *xpad, u16 cmd, unsigned char
(__u16) le16_to_cpup((__le16 *)(data + 8)));
}
+ /* Layer button has a value of 0-4, so its reported as an axis */
+ if (xpad->mapping & MAP_LAYER_BUTTON)
+ input_report_abs(dev, ABS_MISC, data[34]);
+
input_sync(dev);
}
@@ -1622,6 +1638,9 @@ static void xpad_set_up_abs(struct input_dev *input_dev, signed short abs)
case ABS_HAT0Y: /* the d-pad (only if dpad is mapped to axes */
input_set_abs_params(input_dev, abs, -1, 1, 0, 0);
break;
+ case ABS_MISC: /* 4 value layer button (such as on the XAC) */
+ input_set_abs_params(input_dev, abs, 0, 4, 0, 0);
+ break;
default:
input_set_abs_params(input_dev, abs, 0, 0, 0, 0);
break;
@@ -1714,6 +1733,10 @@ static int xpad_init_input(struct usb_xpad *xpad)
xpad_set_up_abs(input_dev, xpad_abs_triggers[i]);
}
+ /* setup layer buton as an axis with 4 possible values */
+ if (xpad->mapping & MAP_LAYER_BUTTON)
+ xpad_set_up_abs(input_dev, ABS_MISC);
+
error = xpad_init_ff(xpad);
if (error)
goto err_free_input;
base-commit: 15205c2829ca2cbb5ece5ceaafe1171a8470e62b
--
2.30.2
Hey,
On Wed, 2022-08-10 at 07:15 -0700, Nate Yocom wrote:
> + /*
> + * X-Box Adaptive controller sets 0x02 when x-box
> button is pressed,
> + * we could probably condense into just data[4] != 0,
> but explicitly
> + * checking here ensures no regression if other
> devices set other bits.
> + */
> + if (le16_to_cpu(xpad->dev->id.vendor) == 0x045e &&
> + le16_to_cpu(xpad->dev->id.product) == 0x0b0a)
> + input_report_key(dev, BTN_MODE, data[4] &
> 0x02);
> + else
> + input_report_key(dev, BTN_MODE, data[4] &
> 0x01);
I won't be able to test the patch until next week, but I would actually
implement what you mention in the comment as a separate patch. This
would avoid having a special-case for a specific VID/PID without a
quirk like "MAP_LAYER_BUTTON" defined, and if it were to cause
problems, it would be straight forward to revert.
On Thu, Aug 11, 2022 at 03:19:50PM +0200, Bastien Nocera wrote:
> Hey,
>
> On Wed, 2022-08-10 at 07:15 -0700, Nate Yocom wrote:
> > + /*
> > + * X-Box Adaptive controller sets 0x02 when x-box
> > button is pressed,
> > + * we could probably condense into just data[4] != 0,
> > but explicitly
> > + * checking here ensures no regression if other
> > devices set other bits.
> > + */
> > + if (le16_to_cpu(xpad->dev->id.vendor) == 0x045e &&
> > + le16_to_cpu(xpad->dev->id.product) == 0x0b0a)
> > + input_report_key(dev, BTN_MODE, data[4] &
> > 0x02);
> > + else
> > + input_report_key(dev, BTN_MODE, data[4] &
> > 0x01);
>
>
> I won't be able to test the patch until next week, but I would actually
> implement what you mention in the comment as a separate patch. This
> would avoid having a special-case for a specific VID/PID without a
> quirk like "MAP_LAYER_BUTTON" defined, and if it were to cause
> problems, it would be straight forward to revert.
Thanks for the feedback, should I make this a series of 3 successive patches then?
1) Add the device to xpad_device[]
2) Support the Layer button with MAP_LAYER_BUTTON
3) Support the X-Box button (as suggested in the comment instead of
VID/PID checks)
On Sat, Aug 13, 2022 at 10:09:48AM -0700, Nate Yocom wrote:
> On Thu, Aug 11, 2022 at 03:19:50PM +0200, Bastien Nocera wrote:
> > Hey,
> >
> > On Wed, 2022-08-10 at 07:15 -0700, Nate Yocom wrote:
> > > + /*
> > > + * X-Box Adaptive controller sets 0x02 when x-box
> > > button is pressed,
> > > + * we could probably condense into just data[4] != 0,
> > > but explicitly
> > > + * checking here ensures no regression if other
> > > devices set other bits.
> > > + */
> > > + if (le16_to_cpu(xpad->dev->id.vendor) == 0x045e &&
> > > + le16_to_cpu(xpad->dev->id.product) == 0x0b0a)
> > > + input_report_key(dev, BTN_MODE, data[4] &
> > > 0x02);
> > > + else
> > > + input_report_key(dev, BTN_MODE, data[4] &
> > > 0x01);
> >
> >
> > I won't be able to test the patch until next week, but I would actually
> > implement what you mention in the comment as a separate patch. This
> > would avoid having a special-case for a specific VID/PID without a
> > quirk like "MAP_LAYER_BUTTON" defined, and if it were to cause
> > problems, it would be straight forward to revert.
>
> Thanks for the feedback, should I make this a series of 3 successive patches then?
>
> 1) Add the device to xpad_device[]
> 2) Support the Layer button with MAP_LAYER_BUTTON
> 3) Support the X-Box button (as suggested in the comment instead of
> VID/PID checks)
Actually, it occurs to me that I can just mask for 0x03 to allow both
existing and the new controller to work - without a VID/PID check. I'll
test and break into a multipart patch v3 shortly.