Hello, Does anybody have any additional feedback on this revision of the patchset? Thanks, Daniel On Sun, Mar 10, 2019 at 9:03 PM Daniel J. Ogorchock <djogorchock@xxxxxxxxx> wrote: > > TODO: > - Gyroscope support > - Figure out more details on not breaking SDL > > 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 > > This patch revision adds support for setting the Home LED brightness in > addition to rumble support. The switch controllers have configurable > motor frequencies. This is useful for playing different tones or sound > effects on the controllers. I added sysfs attributes for controlling the > rumble frequencies from userspace. I didn't see an obvious existing > sysfs class that provided that functionality. Please let me know if > there's a preferable way to do this. > > I think the last major feature to add is the gyro support. I assume the > preferred way to handle this would be to create a new input device for > the gyro which is separate from the gamepad. > > I'm still running into the issue of led classdev errors when unplugging > the controller (it returns -ENOSYS). See the patch v3 summary for more > info on what I've tried so far. > > Roderick, > As a followup to the prior discussion about patching the version to > prevent breaking SDL compatibility: > > I took a look at libsdl, and it looks like it's using hidraw to > implement its own userspace switch pro controller driver. When it > detects compatibility it's only checking the vendor and id values (the > function takes in a version argument, but it doesn't use it). > > If I start up Steam, it seems to yank control away from my kernel driver > and do everything itself. I'm not sure what the correct way forward is > on this. Do I need to patch the version if SDL seems unaffected by the > kernel driver? > > Thanks, > Daniel > > -- Daniel Ogorchock
