It seems like this USB VID is not officially assigned, so let's create a
hid-ids.h entry without a vendor or product name.
Signed-off-by: Max Staudt <[email protected]>
---
drivers/hid/hid-ids.h | 3 +++
drivers/hid/hid-playstation.c | 4 ++++
2 files changed, 7 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 72046039d1be..df831ab464a4 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -22,6 +22,9 @@
#define USB_DEVICE_ID_3M2256 0x0502
#define USB_DEVICE_ID_3M3266 0x0506
+#define USB_VENDOR_ID_7545 0x7545
+#define USB_DEVICE_ID_7545_0104 0x0104
+
#define USB_VENDOR_ID_A4TECH 0x09da
#define USB_DEVICE_ID_A4TECH_WCP32PU 0x0006
#define USB_DEVICE_ID_A4TECH_X5_005D 0x000a
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index a0eb36d695d9..0aa474f1e96f 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -2747,6 +2747,10 @@ static const struct hid_device_id ps_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER_DONGLE),
.driver_data = PS_TYPE_PS4_DUALSHOCK4 },
+ /* Third-party controllers identifying as "SZ-MYPOWER" */
+ { HID_USB_DEVICE(USB_VENDOR_ID_7545, USB_DEVICE_ID_7545_0104),
+ .driver_data = PS_TYPE_PS4_DUALSHOCK4 },
+
/* Sony DualSense controllers for PS5 */
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS5_CONTROLLER),
.driver_data = PS_TYPE_PS5_DUALSENSE },
--
2.39.2
On Mon, Jan 15, 2024 at 6:52 AM Max Staudt <[email protected]> wrote:
>
> It seems like this USB VID is not officially assigned, so let's create a
> hid-ids.h entry without a vendor or product name.
>
> Signed-off-by: Max Staudt <[email protected]>
> ---
> drivers/hid/hid-ids.h | 3 +++
> drivers/hid/hid-playstation.c | 4 ++++
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 72046039d1be..df831ab464a4 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -22,6 +22,9 @@
> #define USB_DEVICE_ID_3M2256 0x0502
> #define USB_DEVICE_ID_3M3266 0x0506
>
> +#define USB_VENDOR_ID_7545 0x7545
> +#define USB_DEVICE_ID_7545_0104 0x0104
> +
> #define USB_VENDOR_ID_A4TECH 0x09da
> #define USB_DEVICE_ID_A4TECH_WCP32PU 0x0006
> #define USB_DEVICE_ID_A4TECH_X5_005D 0x000a
> diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
> index a0eb36d695d9..0aa474f1e96f 100644
> --- a/drivers/hid/hid-playstation.c
> +++ b/drivers/hid/hid-playstation.c
> @@ -2747,6 +2747,10 @@ static const struct hid_device_id ps_devices[] = {
> { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER_DONGLE),
> .driver_data = PS_TYPE_PS4_DUALSHOCK4 },
>
> + /* Third-party controllers identifying as "SZ-MYPOWER" */
> + { HID_USB_DEVICE(USB_VENDOR_ID_7545, USB_DEVICE_ID_7545_0104),
> + .driver_data = PS_TYPE_PS4_DUALSHOCK4 },
> +
> /* Sony DualSense controllers for PS5 */
> { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS5_CONTROLLER),
> .driver_data = PS_TYPE_PS5_DUALSENSE },
> --
> 2.39.2
>
>
I'm not familiar with this device, but if it indeed works. Then I'm
okay with it.
Thanks,
Roderick
On 1/25/24 10:03, Roderick Colenbrander wrote:
> I'm not familiar with this device, but if it indeed works. Then I'm
> okay with it.
Thanks!
I've just tried this patch on real hardware again, and there's a tradeoff here - it improves the situation for one 7545:0104 controller, and worsens it for another.
Up to you, and if you don't want to think about it, then let's shelve this patch :)
Details follow, if you're curious.
I have two controllers with VID/PID 7545:0104, and they're both very quirky multi-emulation devices. One is shaped like a PS4 controller, the other like a hybrid between a PS4 and a Switch controller. Since these controllers exhibit all of the USB related quirks in this series, I've kept them as reproducers. Other controllers that passed through my hands only had a subset of the quirks.
Up until now, both controllers worked with hid-sony as PS3 controllers. With this patch, the PS4 controller gains LED support and fine-grained control of the weak rumble motor. The "Switch (?) controller" on the other hand errors out, becomes 0079:181c, and loses the Home key and the accelerometer. This is a user facing change, and the question is how much we really care about these controllers.
More details, if you're still reading:
Both are "multi-purpose" controllers, appearing as PS4/PS3/Switch/other controllers in sequence. They advertise themselves as one USB device, and if there is no driver sending whatever init sequence they expect, they disconnect and try emulating a different controller.
The PS4 controller has rumble and an RGB LED, and this patch series improves its functionality. It cannot emulate a Switch controller.
The Switch (?) controller has no rumble and four multicolour player LEDs, but it adds Switch compatibility including accelerometer and gyro.
For the PS4 mode, which is the first that they try, and which would unify most functions, they use 7545:0104 instead of cloning a DS4 VID/PID. So I took a guess and found that it works fine with hid-playstation if I add the VID/PID and the init quirks in patches 2/3/4. Well, to be precise, I've only made the DS4 shaped one work in PS4 mode, the Switch controller isn't happy and errors out, see below.
On the PS4 controller, this makes the RGB LED work, rumble works, but the gyro and touchpad don't send HID updates. The touchpad can click though, so maybe the controller I have has a hardware defect.
The Switch (?) controller is where things get weird. It disconnects, even though it is initialised by hid-playstation, and transitions into a generic controller with VID/PID 0079:181c. This mode is *not* on the list of emulations it usually tries. It's as if the "unfinished" PS4 initialisation transitions it into a hidden fifth emulation mode. In this mode, the home key does not send any HID event, and there are no accelerometer updates that hid-sony would receive in PS3 mode.
So, with this patch, the PS4 controller works better on Linux, while the Switch controller works worse. Both were seen as PS3 controllers up until now. I see no way to discern them at driver probe time.
Any preference on what to do...?
Max
On Sat, Jan 27, 2024 at 3:16 AM Max Staudt <[email protected]> wrote:
>
> On 1/25/24 10:03, Roderick Colenbrander wrote:
> > I'm not familiar with this device, but if it indeed works. Then I'm
> > okay with it.
>
> Thanks!
>
>
> I've just tried this patch on real hardware again, and there's a tradeoff here - it improves the situation for one 7545:0104 controller, and worsens it for another.
>
> Up to you, and if you don't want to think about it, then let's shelve this patch :)
>
>
>
> Details follow, if you're curious.
>
>
> I have two controllers with VID/PID 7545:0104, and they're both very quirky multi-emulation devices. One is shaped like a PS4 controller, the other like a hybrid between a PS4 and a Switch controller. Since these controllers exhibit all of the USB related quirks in this series, I've kept them as reproducers. Other controllers that passed through my hands only had a subset of the quirks.
>
> Up until now, both controllers worked with hid-sony as PS3 controllers. With this patch, the PS4 controller gains LED support and fine-grained control of the weak rumble motor. The "Switch (?) controller" on the other hand errors out, becomes 0079:181c, and loses the Home key and the accelerometer This is a user facing change, and the question is how much we really care about these controllers.
>
>
>
> More details, if you're still reading:
>
>
> Both are "multi-purpose" controllers, appearing as PS4/PS3/Switch/other controllers in sequence. They advertise themselves as one USB device, and if there is no driver sending whatever init sequence they expect, they disconnect and try emulating a different controller.
>
> The PS4 controller has rumble and an RGB LED, and this patch series improves its functionality. It cannot emulate a Switch controller.
>
> The Switch (?) controller has no rumble and four multicolour player LEDs, but it adds Switch compatibility including accelerometer and gyro.
>
>
> For the PS4 mode, which is the first that they try, and which would unify most functions, they use 7545:0104 instead of cloning a DS4 VID/PID. So I took a guess and found that it works fine with hid-playstation if I add the VID/PID and the init quirks in patches 2/3/4. Well, to be precise, I've only made the DS4 shaped one work in PS4 mode, the Switch controller isn't happy and errors out, see below.
>
>
> On the PS4 controller, this makes the RGB LED work, rumble works, but the gyro and touchpad don't send HID updates. The touchpad can click though, so maybe the controller I have has a hardware defect.
>
> The Switch (?) controller is where things get weird. It disconnects, even though it is initialised by hid-playstation, and transitions into a generic controller with VID/PID 0079:181c. This mode is *not* on the list of emulations it usually tries. It's as if the "unfinished" PS4 initialisation transitions it into a hidden fifth emulation mode. In this mode, the home key does not send any HID event, and there are no accelerometer updates that hid-sony would receive in PS3 mode.
>
>
> So, with this patch, the PS4 controller works better on Linux, while the Switch controller works worse. Both were seen as PS3 controllers up until now. I see no way to discern them at driver probe time.
>
> Any preference on what to do...?
>
>
>
> Max
>
Hmpf, euhm euhm I'm not entirely sure what makes sense. From the
sounds of it are somewhat broken devices (buggy firmwares on them) or
perhaps one of your controllers (the one with not working touch) is
perhaps broken.
Some of the patches like handling report id 0x1 (minimal) won't hurt,
the LED fixes won't either. It makes it easier to add more devices. I
wonder if we have fully have enough data.
Need to think a bit...
Roderick
On 1/31/24 06:07, Roderick Colenbrander wrote:
> Hmpf, euhm euhm I'm not entirely sure what makes sense. From the
> sounds of it are somewhat broken devices (buggy firmwares on them) or
> perhaps one of your controllers (the one with not working touch) is
> perhaps broken.
>
> Some of the patches like handling report id 0x1 (minimal) won't hurt,
> the LED fixes won't either. It makes it easier to add more devices. I
> wonder if we have fully have enough data.
>
> Need to think a bit...
Yeah, maybe for now, let's focus on the patches that you don't see much trouble with. Better to enable some devices, than none.
I suggest dropping this here patch (enabling 7545:0104) for now, and if there's ever a change of mind, we can just pick it from the LKML archives :)
You can also drop the other patch that you're uneasy about, since I believe these 7545:0104 devices are the only ones I've observed to not implement the what-is-your-MAC-address command.
Max
On Wed, Jan 31, 2024 at 6:48 AM Max Staudt <[email protected]> wrote:
>
> On 1/31/24 06:07, Roderick Colenbrander wrote:
> > Hmpf, euhm euhm I'm not entirely sure what makes sense. From the
> > sounds of it are somewhat broken devices (buggy firmwares on them) or
> > perhaps one of your controllers (the one with not working touch) is
> > perhaps broken.
> >
> > Some of the patches like handling report id 0x1 (minimal) won't hurt,
> > the LED fixes won't either. It makes it easier to add more devices. I
> > wonder if we have fully have enough data.
> >
> > Need to think a bit...
>
> Yeah, maybe for now, let's focus on the patches that you don't see much trouble with. Better to enable some devices, than none.
>
> I suggest dropping this here patch (enabling 7545:0104) for now, and if there's ever a change of mind, we can just pick it from the LKML archives :)
>
>
> You can also drop the other patch that you're uneasy about, since I believe these 7545:0104 devices are the only ones I've observed to not implement the what-is-your-MAC-address command.
>
>
>
> Max
>
I agree it sounds like a good idea for now to drop just those 2 paches
and just see what other devices are out there (SDL2 has a good ds4
implementation too and they dealt with a lot of devices). May need to
get some of the 8bitdo and many others to see some patterns.
Thanks,
Roderick
On 2/1/24 01:34, Roderick Colenbrander wrote:
> I agree it sounds like a good idea for now to drop just those 2 paches
> and just see what other devices are out there (SDL2 has a good ds4
> implementation too and they dealt with a lot of devices). May need to
> get some of the 8bitdo and many others to see some patterns.
8BitDo seem to be interesting indeed. IIRC they need the patches for the firmware version, the gyro calibration, and 0x01 events.
Max