Re: [PATCH 00/13] HID: new driver for PS5 'DualSense' controller

[<Roderick.Colenbrander@sony.com>]

Hey Bastian,

> From: Bastien Nocera <hadess@hadess.net>
> Sent: Saturday, December 19, 2020 12:38 AM
> To: roderick@gaikai.com <roderick@gaikai.com>; Jiri Kosina <jikos@kernel.org>; Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Cc: linux-input@vger.kernel.org <linux-input@vger.kernel.org>; Chris Ye <lzye@google.com>; Colenbrander, Roderick <Roderick.Colenbrander@sony.com>
> Subject: Re: [PATCH 00/13] HID: new driver for PS5 'DualSense' controller 
>  
> Hey Roderick,
> 
> On Fri, 2020-12-18 at 22:23 -0800, Roderick Colenbrander wrote:
> > From: Roderick Colenbrander <roderick.colenbrander@sony.com>
> > 
> > Hi,
> > 
> > I am pleased to share a new Linux driver for the PlayStation 5
> > 'DualSense'
> > game controller. The driver supports the DualSense in both Bluetooth
> > and USB modes. Most controller features are supported including LEDs,
> > Touchpad, Motion Sensors and Rumble.

> Excellent, this is a nice early holiday present :)
> I've just received a DualSense controller so I'll try to test this in
> the coming days.

> > DualSense supported is implemented in a new 'hid-playstation' driver,

> "hid-sony-playstation"? Not sure how much the input/hid tree
> maintainers will want to force this, but the same problem is going to
> show up for the hid-based XBox controller driver (hid-xbox, or hid-
> microsoft-xbox?) as hid-microsoft is as busy as hid-sony.

I had some offline conversation prior with Jiri and Benjamin. I wanted to avoid keeping PlayStation devices in hid-sony as Sony is a large group of companies and as 'PlayStation' we don't have any authority over those devices. When discussing we felt that hid-playstation was the best name. Technically the PlayStation company is "Sony Interactive Entertainment", but a a "hid-sie" wouldn't see any name recognition.

Other crowded drivers at some point could use a split as well as having too many devices in there can be a problem. Not just for maintenance, but also for device integration (e.g. phones, TVs,..), though not a main worry for the open kernel. Just for context in such embedded devices you may only want to pull in the 'game controller' driver and not the full weight of a hid-microsoft or a hid-sony. In case of hid-sony for example there is support for TV remotes as well, which cause collisions with whatever proprietary user/kernel mode TV remote support the device already used.

> > which
> > will be used for peripherals by 'Sony Interactive Entertainment'
> > (PlayStation).
> > Hid-sony will be used for devices for the larger Sony Group. We
> > intend to
> > migrate existing devices over time gradually to hid-playstation. We
> > do not
> > want to cause any regressions and maintain quality. As such moving
> > forward,
> > unit tests are important and we started by providing these through
> > 'hid-tools'
> including DualSense.

> I know it's not your job to handle those, but be careful with not
> breaking the clone controllers. Plenty of folks use them, for better or
> for worse.

Support for DualShock 4 is easy to migrate, but I'm really, really nervous about the DualShock 3 generation with many buggy clones. Some of it is due to broken HID reports (even though the practical reports must use the same byte layout as the DualShock 3). Not using the HID parser and parsing raw reports directly may mitigate some of that (the HID report is fully with vendor specific stuff anyway). But yeah it is a pain and I don't know if I want to dare trying DualShock 3... but will see where that goes. Normally it is tricky for us to support clone devices, but if this migration happened we would have to pay attention to it and perhaps get these devices on Ebay.

> > 
> > The Linux driver exposes DualSense functionality as a 'compositive
> > device'
> > similar to DualShock 4 in hid-sony, spanning multiple frameworks.
> > First,
> > it exposes 3 evdev nodes for respectively the 'gamepad', 'touchpad'
> > and
> > 'motion sensors'. The FF framework is used to provide basic rumble
> > features.
> > The leds-class is used to implement the Player indicator LEDs below
> > the
> > DualSense's touchpad, while the new 'leds-class-multicolor' is used
> > for
> > the lightbars next to the touchpad.
> > 
> > Not yet supported are new unique features introduced by the DualSense
> > such as Adaptive Triggers and the VCM based Haptics. These features
> > require
> > a large amount of data and complex data structures. It is not clear
> > how to
> > expose these. The current Evdev and FF frameworks are too limiting.
> > We hope
> > to have a dialog on how to expose these over time in a generic way.
> > 
> > Enjoy the new DualSense driver and let us know if you have any
> > questions
> > or feedback.

> Is the audio jack on the controller already supported, or would that be
> part of the features that aren't supported yet?

The answer is yes and no. In case of USB, there is some level of audio support, though I am not yet sure if I like it.

Basically the VCM haptics, microphone and speaker appears as a USB audio device. It means they kind of work. Though some of the audio control features are HID managed, so they are not there (I haven't seen what audio controls are native exposed through USB). I don't know if the headphone jack currently works or if that needs some MUXing logic through HID.

Bluetooth is not supported at all. It is some custom protocol over HID of which I don't know the details.

Provided we can contribute such support in the future, it is beyond complicated. Just in the 'simple' USB audio case, some interop might be needed with the USB audio drivers for e.g. audio controls. Also the new VCM haptics seem to be reported as audio channels on this device as well. Should haptics really be audio? Or some new interface (a hypothetical EV_FF2)?

> Do you think you might be able to share the information regarding how
> the cable pairing is done, so we can add this support to bluez? I'm
> fine with only sharing the implementation if you prefer to give me the
> details privately (or through my employer).

> Cheers

Thanks,
Roderick