mbox series

[v12,00/14] HID: nintendo

Message ID 20200823044157.339677-1-djogorchock@gmail.com
Headers show
Series HID: nintendo | expand

Message

Daniel Ogorchock Aug. 23, 2020, 4:41 a.m. UTC
I've included round 2 for the IMU support patch. The documentation is
improved and the precision increased for the gyroscope values reported
to userspace.

There is still the important question of how to deal with userspace
implementing custom drivers using hidraw (i.e. Steam). I am resistant to
having hid-nintendo completely yield when userspace uses hidraw, since
that would prevent other applications from receiving the events from the
controllers (like maybe someone configures a voip client to use one of
the triggers as push-to-talk).

In my personal testing with steam, I don't see much issue since I
introduced the patch to not send rumble subcommands when no effect is
playing. Steam/hid-nintendo seem to fight when hid-nintendo is sending
lots of subcommands (e.g. rumble, setting LEDs). Others have reported
though that hid-nintendo/Steam are still fighting even with that patch.

I guess there's not much that can be done though to guarantee a
userspace and kernel driver coexisting at the same time, since one of
them could completely reconfigure the controller's reporting mode, IMU
resolution, etc.

The two extremes seem to be either having the hid drivers yield to
userspace completely when hidraw is in use (e.g. hid-steam with its
virtual hidraw dev) or mask out exposing the hidraw device when a kernel
hid driver is being used. It feels wrong to have things in the current
state where the HIDRAW device is being exposed, but it's not actually
supported.

Version 12 changes:
  - Added support for reading user calibration from the controller's
    SPI flash (written when someone calibrates the controller on the
    Nintendo switch).
  - Added patch to prevent sending rumble subcommands when no effect
    is being played. This turned out to drastically improve bluetooth
    connection reliability.
  - Set the battery description to POWER_SUPPLY_TYPE_BATTERY (was
    missing in previous revisions due to oversight). This fixes problems
    with desktop environments not handling the controller batteries
    properly.
  - Reintroduced IMU patch with improvements to documentation, packet
    drop handling, and increased precision for gyro readings. Also
    now blacklists the IMU input dev from joydev like hid-sony.

Version 11 changes:
  - Removed IMU patch for now, since it has some issues to work out.
  - Fixed bug introduced in v10 which led to the joy-cons' S-triggers
    not being configured as an input.
  - Changed the pro controller's d-pad input from buttons to a hat to be
    more in line with other controller drivers.

Version 10 changes:
  - Removed duplicate reporting of one of the triggers that Billy noticed
  - The joy-cons now only report having the buttons they actually have
    (they used to register the input devices with the buttons of the
    other joy-con as well).
  - The input device is now created after the LEDs/power supply.
  - The removed state handling bool has been removed, instead opting to
    add a new controller state (removed).
  - Eliminated a 1 second delay when probing a USB controller.
  - Added support for the IMU. This mostly consisted of merging in some
    work provided by Carl. I'm not incredibly familiar with proper
    gyro/accelerometer handling in linux, so this might need some
    tweaking. Preliminary tests in evtest show the gyro/accel values
    being reported.
  - Added support for the joy-con USB charging grip.

Version 9 changes:
  - Fixed compiler errors on gcc versions older than 8.2
  - Set input device's uniq value to the controller's MAC address

Version 8 changes:
  - Corrected the handshaking protocol with USB pro controllers. A
    handshake now occurs both prior and after the baudrate set. This
    doesn't appear to have a noticeable difference, but it more
    accurately follows documentation found online.
  - Fixed potential race condition which could lead to a slightly longer
    delay sending subcommands in rare circumstances.
  - Moved the rumble worker to its own workqueue, since it can block.
    This prevents it from having a negative impact on the default kernel
    workqueue. It also prevents dropped subcommands due to something
    else blocking the kernel workqueue. The benefit is most obvious when
    using multiple controllers at once, since the controller subcommand
    timings are very picky.
  - Added a patch to set the most significant bit of the hid hw version.
    Roderick had mentioned needing to probably do this awhile ago, but I
    had forgotten about it until now. This is the same thing hid-sony
    does. It allows SDL2 to have different mappings for the hid-nintendo
    driver vs the default hid mappings.

Version 7 changes:
  - Changed name to hid-nintendo to fit modern naming conventions
  - Removed joycon_ctlr_destroy(), since it wasn't needed an could
    potentially invalidate a mutex while it could be in use on other
    threads
  - Implemented minor code improvements suggested by Silvan
  - The driver now waits to send subcommands until after receiving an
    input report. This significantly reduces dropped subcommands.
  - Reduced the number of error messages when disconnecting a
    controller.

Version 6 changes:
  - Improved subcommand sending reliabilty
  - Decreased rumble period to 50ms
  - Added rumble queue to avoid missing ff_effects if sent too quickly
  - Code cleanup and minor refactoring
  - Added default analog stick calibration

Version 5 changes:
  - Removed sysfs interface to control motor frequencies.
  - Improved rumble reliability by using subcommands to set it.
  - Changed mapping of the SL/SR triggers on the joy-cons to map to
    whichever triggers they lack (e.g. a left joycon's sl/sr map to
    TR and TR2). This allows userspace to distinguish between the
    normal and S triggers.
  - Minor refactors

Version 4 changes:
  - Added support for the Home button LED for the pro controller and
    right joy-con
  - Changed name from hid-switchcon to hid-joycon
  - Added rumble support
  - Removed ctlr->type and use hdev->product instead
  - Use POWER_SUPPLY_CAPACITY_LEVEL enum instead of manually translating
    to capacity percentages
  - Misc. minor refactors based on v3 feedback

Version 3 changes:
  - Added led_classdev support for the 4 player LEDs
  - Added power_supply support for the controller's battery
  - Made the controller number mutex static
  - Minor refactoring/style fixes based on Roderick's feedback from v2

Version 2 changes:
  - Switched to using a synchronous method for configuring the
        controller.
  - Removed any pairing/orientation logic in the driver. Every
    controller now corresponds to its own input device.
  - Store controller button data as a single u32.
  - Style corrections

Daniel J. Ogorchock (14):
  HID: nintendo: add nintendo switch controller driver
  HID: nintendo: add player led support
  HID: nintendo: add power supply support
  HID: nintendo: add home led support
  HID: nintendo: add rumble support
  HID: nintendo: improve subcommand reliability
  HID: nintendo: send subcommands after receiving input report
  HID: nintendo: reduce device removal subcommand errors
  HID: nintendo: patch hw version for userspace HID mappings
  HID: nintendo: set controller uniq to MAC
  HID: nintendo: add support for charging grip
  HID: nintendo: add support for reading user calibration
  HID: nintendo: prevent needless queueing of the rumble worker
  HID: nintendo: add IMU support

 MAINTAINERS                |    6 +
 drivers/hid/Kconfig        |   24 +
 drivers/hid/Makefile       |    1 +
 drivers/hid/hid-ids.h      |    4 +
 drivers/hid/hid-nintendo.c | 2240 ++++++++++++++++++++++++++++++++++++
 drivers/input/joydev.c     |   10 +
 6 files changed, 2285 insertions(+)
 create mode 100644 drivers/hid/hid-nintendo.c

Comments

Jiri Kosina Aug. 27, 2020, 9:22 a.m. UTC | #1
On Sat, 22 Aug 2020, Daniel J. Ogorchock wrote:

> I've included round 2 for the IMU support patch. The documentation is
> improved and the precision increased for the gyroscope values reported
> to userspace.
> 
> There is still the important question of how to deal with userspace
> implementing custom drivers using hidraw (i.e. Steam). I am resistant to
> having hid-nintendo completely yield when userspace uses hidraw, since
> that would prevent other applications from receiving the events from the
> controllers (like maybe someone configures a voip client to use one of
> the triggers as push-to-talk).
> 
> In my personal testing with steam, I don't see much issue since I
> introduced the patch to not send rumble subcommands when no effect is
> playing. Steam/hid-nintendo seem to fight when hid-nintendo is sending
> lots of subcommands (e.g. rumble, setting LEDs). Others have reported
> though that hid-nintendo/Steam are still fighting even with that patch.
> 
> I guess there's not much that can be done though to guarantee a
> userspace and kernel driver coexisting at the same time, since one of
> them could completely reconfigure the controller's reporting mode, IMU
> resolution, etc.
> 
> The two extremes seem to be either having the hid drivers yield to
> userspace completely when hidraw is in use (e.g. hid-steam with its
> virtual hidraw dev) or mask out exposing the hidraw device when a kernel
> hid driver is being used. It feels wrong to have things in the current
> state where the HIDRAW device is being exposed, but it's not actually
> supported.

Could you please elaborate a little bit better about this conflict? 
hid-steam and hid-nintendo seem to be supporting different VID/PID 
combinations, so that's not the conflict I guess.

Is Steam implementing some (proprietary?) userspace driver for conflicting 
VID/PID with hid-nintendo, using hidraw?

Thanks,
Daniel Ogorchock Aug. 27, 2020, 3:23 p.m. UTC | #2
>
> Could you please elaborate a little bit better about this conflict?
> hid-steam and hid-nintendo seem to be supporting different VID/PID
> combinations, so that's not the conflict I guess.
>
> Is Steam implementing some (proprietary?) userspace driver for conflicting
> VID/PID with hid-nintendo, using hidraw?
>
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
>

Hi Jiri,

Yes, Steam implements its own userspace driver using hidraw for the
nintendo switch pro controller. As things stand now, this can lead to
issues when running Steam while the hid-nintendo driver is in use,
where userspace and the kernel can be both sending reports to the
controller. My understanding is that hid-steam uses a virtual hidraw
device to workaround a similar issue with the steam controller
(backing off and not sending reports when it sees hidraw in use).

hid-nintendo does set the most significant bit of the the hid device's
version to allow userspace to distinguish from the standard hid driver
(same thing hid-sony does for things like libSDL mappings). Maybe that
will be sufficient for applications to choose whether to use their own
userspace driver or not. I'm not sure if that's considered acceptable
in the spirit of trying not to break userspace functionality.

Thanks,
Daniel