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.
> 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?
> 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
