[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Yvfrj11PBPmNXHeN@ghaven-kernel>
Date: Sat, 13 Aug 2022 11:21:03 -0700
From: Nate Yocom <nate@...om.org>
To: Bastien Nocera <hadess@...ess.net>
Cc: dmitry.torokhov@...il.com, linux-input@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] Input: joystick: xpad: Add X-Box Adaptive Controller
support
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.
Powered by blists - more mailing lists