(Sorry for resending this and the other reply, Bastien. I failed to reply-all.)
Hi Bastien,
On Mon, Jan 28, 2019 at 6:48 AM Bastien Nocera <hadess@xxxxxxxxxx> wrote:
>
> Hey Daniel,
>
> On Sun, 2019-01-27 at 22:04 -0600, Daniel J. Ogorchock wrote:
> > Thank you for the feedback on the v2 patch.
>
> As I've mentioned to Benjamin when you sent your first version, I spent
> some time last month cleaning up a user-space joycon implementation in
> order to port it to the kernel. I ended up not finishing it as I was
> hogging a Switch Pro controller that wasn't mine, and didn't have any
> joycons.
>
> I'll add a few comments in this thread.
>
> First is the name of the driver. I don't like "switchcon", because it's
> not a term that anyone uses to refer to either of the devices the
> driver supports. How about "hid-joycon" ("This also supports the Pro
> controller"), or "hid-nintendo-switch", or maybe something with "nx" in
> the name (that was the Switch's codename)?
>
> I think hid-joycon is the clearest one.
>
This seems to be the consensus. I'll definitely change the name.
> > TODO:
> > - Rumble suport
> > - Gyroscope support
> > - Home Button LED support
> >
> > 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
> >
> >
> > When implementing the led_classdev support, I noticed that when
> > disconnecting the controller I get warnings where the led subsystem
> > fails to set the leds' brightnesses. I get an ENOSYS when
> > disconnecting
> > USB and an EIO when disconnecting bluetooth. I'm not sure if this is
> > typical or if I'm missing some explicit deinitialization in my
> > driver.
> > I tried adding LED_HW_PLUGGABLE hoping for that to fix the USB
> > disconnect
> > case, but I think that only ignores ENOENTs.
>
> Which call is it you get those return value for?
>
It occurs in led-core.c's set_brightness_delayed().
> > Also, the controller reports the battery status as five discreet
> > steps.
> > I mapped those to seemingly appropriate capacity integers, but maybe
> > there's a standard way to handle this I'm not aware of.
>
> There's an unnamed enum for this purpose in
> include/linux/power_supply.h:
> enum {
> POWER_SUPPLY_CAPACITY_LEVEL_UNKNOWN = 0,
> POWER_SUPPLY_CAPACITY_LEVEL_CRITICAL,
> POWER_SUPPLY_CAPACITY_LEVEL_LOW,
> POWER_SUPPLY_CAPACITY_LEVEL_NORMAL,
> POWER_SUPPLY_CAPACITY_LEVEL_HIGH,
> POWER_SUPPLY_CAPACITY_LEVEL_FULL,
> };
>
> Look for "capacity level" in Documentation/power/power_supply_class.txt
> Do _not_ add capacity percentages, user-space (UPower) will take care
> of adding such a percentage for the parts of the OS that don't support
> capacity levels/coarse battery level reporting.
>
> Cheers
>
Thanks. This is exactly what I was looking for.
-Daniel
