mbox series

[v3,0/4] HID: wiiu-drc: Add a driver for the Wii U gamepad

Message ID 20210519085924.1636-1-linkmauve@linkmauve.fr (mailing list archive)
Headers show
Series HID: wiiu-drc: Add a driver for the Wii U gamepad | expand

Message

Link Mauve May 19, 2021, 8:59 a.m. UTC
This driver is for the DRC (wireless gamepad) when plugged to the DRH of
the Wii U, a chip exposing it as a USB device.

I tried to use this driver on master over usbip on my laptop, but usbip
disconnects the device right after the driver created the
/dev/input/event* files, so instead I have only tested this driver on
the 4.19 branch of the linux-wiiu[1] downstream.

Other than that, pretty much all of the HID parts of the gamepad work,
it’s only missing microphone, camera and NFC input now but those are
mostly standard (read require quirks) and pertain to other subsystems,
so I felt like this can be upstreamed already.

[1] https://gitlab.com/linux-wiiu/linux-wiiu

Changes since v1:
- Rename interfaces to be less redundant.
- Add comments for potentially unclear things.
- Reword some commits to include more needed information.
- Include all needed includes.
- Use helpful helper functions instead of (badly) reimplementing them
  myself.
- Always return the correct type for each function, to avoid some
  bool/int confusion, or returning 0 to mean error.
- Use myself as the module author, even though Ash did most of the
  initial work, I’m the one who will be maintaining this module from now
  on.
- Use input_set_capability() instead of set_bit(…, keybit) to also set
  BIT(EV_KEY) on evbit[0].
- Call hid_hw_start() before input_register_device() but after the setup
  functions, so that hid_hw_open() is never called before it.
- Add missing spin_lock_init() for the battery lock.
- Use a static atomic for the drc_num, and remove the comment about
  using the interface number.
- Interpret battery report as the voltage coming from an ADC, instead of
  the completely wrong ENERGY_NOW it was before.

So basically addressing Jonathan’s and Barnabás’ comments. :)

Changes since v2:
- Guard against the possibility of CONFIG_HID_BATTERY_STRENGTH not
  having been selected.
- Include forgotten linux/fixp-arith.h header.
- Fix a warning in clamp() due to comparing a s16 with a #define.

Ash Logan (1):
  HID: wiiu-drc: Add a driver for this gamepad

Emmanuel Gil Peyrot (3):
  HID: wiiu-drc: Implement touch reports
  HID: wiiu-drc: Add accelerometer, gyroscope and magnetometer readings
  HID: wiiu-drc: Add battery reporting

 drivers/hid/Kconfig        |   7 +
 drivers/hid/Makefile       |   1 +
 drivers/hid/hid-ids.h      |   1 +
 drivers/hid/hid-quirks.c   |   3 +
 drivers/hid/hid-wiiu-drc.c | 564 +++++++++++++++++++++++++++++++++++++
 5 files changed, 576 insertions(+)
 create mode 100644 drivers/hid/hid-wiiu-drc.c

Comments

Link Mauve Sept. 21, 2021, 3:08 p.m. UTC | #1
On Wed, May 19, 2021 at 10:59:20AM +0200, Emmanuel Gil Peyrot wrote:
> This driver is for the DRC (wireless gamepad) when plugged to the DRH of
> the Wii U, a chip exposing it as a USB device.

Hi, I’d like to request a review on this series.  I’ve been using it
with success for quite some months, and from a self-review after not
having touched it for as long it still looks correct. :)

Thanks!
Jiri Kosina Oct. 19, 2021, 9:14 a.m. UTC | #2
On Tue, 21 Sep 2021, Emmanuel Gil Peyrot wrote:

> > This driver is for the DRC (wireless gamepad) when plugged to the DRH of
> > the Wii U, a chip exposing it as a USB device.
> 
> Hi, I’d like to request a review on this series.  I’ve been using it
> with success for quite some months, and from a self-review after not
> having touched it for as long it still looks correct. :)
> 
> Thanks!

[ CCing Daniel ]

Thanks for the patch, and sorry for the delay in the review.

The code looks good to me, the only question/request I'd have is -- would 
it be possible to adhere to the driver naming standards, and actually 
incorporate the support to existing hid-nintendo driver? Or is there any 
substantial reason which I don't see why this wouldn't be a good idea?

Thanks,
Link Mauve Oct. 19, 2021, 9:27 a.m. UTC | #3
On Tue, Oct 19, 2021 at 11:14:02AM +0200, Jiri Kosina wrote:
> On Tue, 21 Sep 2021, Emmanuel Gil Peyrot wrote:
> 
> > > This driver is for the DRC (wireless gamepad) when plugged to the DRH of
> > > the Wii U, a chip exposing it as a USB device.
> > 
> > Hi, I’d like to request a review on this series.  I’ve been using it
> > with success for quite some months, and from a self-review after not
> > having touched it for as long it still looks correct. :)
> > 
> > Thanks!
> 
> [ CCing Daniel ]
> 
> Thanks for the patch, and sorry for the delay in the review.

No worries. :)

> 
> The code looks good to me, the only question/request I'd have is -- would 
> it be possible to adhere to the driver naming standards, and actually 
> incorporate the support to existing hid-nintendo driver? Or is there any 
> substantial reason which I don't see why this wouldn't be a good idea?

I don’t see any existing driver named that way in mainline, would it be
acceptable to simply rename the current patches to hid-nintendo?  What
should be done about the existing hid-wiimote driver then, should it
also be merged alongside?

Another driver I’d like to submit eventually is the GameCube Controller
Adapter for Wii U, which does exactly what its name says, but being an
external USB adapter it also works on any USB computer; would it make
sense to develop it alongside the current driver, just because it is
sold by the same company?

> 
> Thanks,
> 
> -- 
> Jiri Kosina
> SUSE Labs

Thanks,
Jiri Kosina Oct. 19, 2021, 9:30 a.m. UTC | #4
On Tue, 19 Oct 2021, Emmanuel Gil Peyrot wrote:

> > The code looks good to me, the only question/request I'd have is -- would 
> > it be possible to adhere to the driver naming standards, and actually 
> > incorporate the support to existing hid-nintendo driver? Or is there any 
> > substantial reason which I don't see why this wouldn't be a good idea?
> 
> I don’t see any existing driver named that way in mainline, would it be
> acceptable to simply rename the current patches to hid-nintendo?  What
> should be done about the existing hid-wiimote driver then, should it
> also be merged alongside?

hid-nintendo has just recently been staged for 5.16 in 
hid.git#for-5.16/nintendo git branch. Could you please check that?

> Another driver I’d like to submit eventually is the GameCube Controller 
> Adapter for Wii U, which does exactly what its name says, but being an 
> external USB adapter it also works on any USB computer; would it make 
> sense to develop it alongside the current driver, just because it is 
> sold by the same company?

We generally group the support for HID devices in drivers based on the 
producing company, with a few exceptions where it doesn't make sense.

Thanks,
Link Mauve Oct. 19, 2021, 9:36 a.m. UTC | #5
On Tue, Oct 19, 2021 at 11:30:06AM +0200, Jiri Kosina wrote:
> On Tue, 19 Oct 2021, Emmanuel Gil Peyrot wrote:
> 
> > > The code looks good to me, the only question/request I'd have is -- would 
> > > it be possible to adhere to the driver naming standards, and actually 
> > > incorporate the support to existing hid-nintendo driver? Or is there any 
> > > substantial reason which I don't see why this wouldn't be a good idea?
> > 
> > I don’t see any existing driver named that way in mainline, would it be
> > acceptable to simply rename the current patches to hid-nintendo?  What
> > should be done about the existing hid-wiimote driver then, should it
> > also be merged alongside?
> 
> hid-nintendo has just recently been staged for 5.16 in 
> hid.git#for-5.16/nintendo git branch. Could you please check that?

Got it, thanks!

> 
> > Another driver I’d like to submit eventually is the GameCube Controller 
> > Adapter for Wii U, which does exactly what its name says, but being an 
> > external USB adapter it also works on any USB computer; would it make 
> > sense to develop it alongside the current driver, just because it is 
> > sold by the same company?
> 
> We generally group the support for HID devices in drivers based on the 
> producing company, with a few exceptions where it doesn't make sense.

Would it make sense to decouple this driver from the joycon driver?  To
have some kind of sub-driver (possibly with Kconfig entries) for joycon,
wiimote, drc, gc-adapter, maybe more in the future?  I don’t see the drc
code go well into that one C file.  I can handle the split of the joycon
into its own file if that’s a good way forward.

> 
> Thanks,
> 
> -- 
> Jiri Kosina
> SUSE Labs
François-Xavier Carton Oct. 19, 2021, 11:59 p.m. UTC | #6
Hi,

On Tue, Oct 19, 2021 at 11:27:37AM +0200, Emmanuel Gil Peyrot wrote:
> I don’t see any existing driver named that way in mainline, would it be
> acceptable to simply rename the current patches to hid-nintendo?  What
> should be done about the existing hid-wiimote driver then, should it
> also be merged alongside?
> 
> Another driver I’d like to submit eventually is the GameCube Controller
> Adapter for Wii U, which does exactly what its name says, but being an
> external USB adapter it also works on any USB computer; would it make
> sense to develop it alongside the current driver, just because it is
> sold by the same company?
> 

FYI, I've submitted a GC adapter driver previously [1]. I've been using
it since then; the patch still applies to recent kernels. I'd be happy
to work towards having this driver mainlined, if there is interest for
it.

[1] https://patchwork.kernel.org/project/linux-input/list/?series=282859&state=*

Best,
François-Xavier
Link Mauve Oct. 20, 2021, 6:24 a.m. UTC | #7
On Wed, Oct 20, 2021 at 01:59:43AM +0200, François-Xavier Carton wrote:
> Hi,
> 
> On Tue, Oct 19, 2021 at 11:27:37AM +0200, Emmanuel Gil Peyrot wrote:
> > I don’t see any existing driver named that way in mainline, would it be
> > acceptable to simply rename the current patches to hid-nintendo?  What
> > should be done about the existing hid-wiimote driver then, should it
> > also be merged alongside?
> > 
> > Another driver I’d like to submit eventually is the GameCube Controller
> > Adapter for Wii U, which does exactly what its name says, but being an
> > external USB adapter it also works on any USB computer; would it make
> > sense to develop it alongside the current driver, just because it is
> > sold by the same company?
> > 
> 
> FYI, I've submitted a GC adapter driver previously [1]. I've been using
> it since then; the patch still applies to recent kernels. I'd be happy
> to work towards having this driver mainlined, if there is interest for
> it.

I am definitely interested!  I have been using a user-space driver for
the time being, but that’s not a good solution.

> 
> [1] https://patchwork.kernel.org/project/linux-input/list/?series=282859&state=*
> 
> Best,
> François-Xavier
Link Mauve Nov. 4, 2021, 11:21 a.m. UTC | #8
On Tue, Oct 19, 2021 at 11:30:06AM +0200, Jiri Kosina wrote:
> On Tue, 19 Oct 2021, Emmanuel Gil Peyrot wrote:
[…]
> > Another driver I’d like to submit eventually is the GameCube Controller 
> > Adapter for Wii U, which does exactly what its name says, but being an 
> > external USB adapter it also works on any USB computer; would it make 
> > sense to develop it alongside the current driver, just because it is 
> > sold by the same company?
> 
> We generally group the support for HID devices in drivers based on the 
> producing company, with a few exceptions where it doesn't make sense.

Speaking of which, would you want me to also merge hid-wiimote into
hid-nintendo?  Or is there a reason it is separate besides legacy?
François-Xavier Carton Nov. 5, 2021, 5:27 p.m. UTC | #9
On Thu, Nov 04, 2021 at 12:21:37PM +0100, Emmanuel Gil Peyrot wrote:
> On Tue, Oct 19, 2021 at 11:30:06AM +0200, Jiri Kosina wrote:
> > On Tue, 19 Oct 2021, Emmanuel Gil Peyrot wrote:
> […]
> > > Another driver I’d like to submit eventually is the GameCube Controller 
> > > Adapter for Wii U, which does exactly what its name says, but being an 
> > > external USB adapter it also works on any USB computer; would it make 
> > > sense to develop it alongside the current driver, just because it is 
> > > sold by the same company?
> > 
> > We generally group the support for HID devices in drivers based on the 
> > producing company, with a few exceptions where it doesn't make sense.
> 
> Speaking of which, would you want me to also merge hid-wiimote into
> hid-nintendo?  Or is there a reason it is separate besides legacy?
> 

Would naming the drivers with a "nintendo-" prefix while keeping them
separate be an acceptable solution? Since these drivers share no common
code, merging them will result in a big driver with different parts for
unrelated hardware (save for the maker company), which doesn't seem
right.

For the gamecube adapter driver, I'd prefer to keep it separate; but
I'll integrate it to hid-nintendo as Emmanuel did for the wii-u if
that's the preferred option.