diff mbox series

Input: xpad: Remove a conflicting Razer Sabertooth using the VID/PID for the Razer DeathAdder 2013 mouse

Message ID b9e7cb27-1866-83bb-b453-ae265ab6bde6@gmail.com (mailing list archive)
State New, archived
Headers show
Series Input: xpad: Remove a conflicting Razer Sabertooth using the VID/PID for the Razer DeathAdder 2013 mouse | expand

Commit Message

Ismael Ferreras Morezuelas July 30, 2020, 3:44 p.m. UTC
While doing my research to improve the xpad device names I also noticed
that the 1532:0037 VID/PID seems to be used by the DeathAdder 2013,
so that Razer Sabertooth instance looked wrong and very suspect to
me. I didn't see any mention in the official drivers, either.

After doing more research, it turns out that the xpad list
is used by many other projects (like Steam) as-is, this
issue was reported and Valve/Sam Lantinga fixed it:

https://steamcommunity.com/app/353380/discussions/0/1743392486228754770/

(With multiple Internet users reporting similar issues, not linked here)

After not being able to find the correct VID/PID combination anywhere
on the Internet and not receiving any reply from Razer support I did
some additional detective work, it seems like it presents itself as
"Razer Sabertooth Gaming Controller (XBOX360)", code 1689:FE00.

Leaving us with this:
 * Razer Sabertooth (1689:fe00)
 * Razer Sabertooth Elite (24c6:5d04)
 * Razer DeathAdder 2013 (1532:0037) [note: not a gamepad]

So, to sum things up; remove this conflicting/duplicate entry:

{ 0x1532, 0x0037, "Razer Sabertooth", 0, XTYPE_XBOX360 },

As the real/correct one is already present there, even if
the Internet as a whole insists on presenting it as the
Razer Sabertooth Elite, which (by all accounts) is not:

{ 0x1689, 0xfe00, "Razer Sabertooth", 0, XTYPE_XBOX360 },

That's it. No other functional changes intended.

Fixes: f554f619b70 ("Input: xpad - sync device IDs with xboxdrv")
Signed-off-by: Ismael Ferreras Morezuelas <swyterzone@gmail.com>
---
 drivers/input/joystick/xpad.c | 1 -
 1 file changed, 1 deletion(-)

Comments

Cameron Gutman July 31, 2020, 5:54 a.m. UTC | #1
On 7/30/20 8:44 AM, Ismael Ferreras Morezuelas wrote:
> While doing my research to improve the xpad device names I also noticed
> that the 1532:0037 VID/PID seems to be used by the DeathAdder 2013,
> so that Razer Sabertooth instance looked wrong and very suspect to
> me. I didn't see any mention in the official drivers, either.
> 
> After doing more research, it turns out that the xpad list
> is used by many other projects (like Steam) as-is, this
> issue was reported and Valve/Sam Lantinga fixed it:
> 
> https://steamcommunity.com/app/353380/discussions/0/1743392486228754770/
> 
> (With multiple Internet users reporting similar issues, not linked here)
> 
> After not being able to find the correct VID/PID combination anywhere
> on the Internet and not receiving any reply from Razer support I did
> some additional detective work, it seems like it presents itself as
> "Razer Sabertooth Gaming Controller (XBOX360)", code 1689:FE00.
> 
> Leaving us with this:
>  * Razer Sabertooth (1689:fe00)
>  * Razer Sabertooth Elite (24c6:5d04)
>  * Razer DeathAdder 2013 (1532:0037) [note: not a gamepad]
> 
> So, to sum things up; remove this conflicting/duplicate entry:
> 
> { 0x1532, 0x0037, "Razer Sabertooth", 0, XTYPE_XBOX360 },
> 
> As the real/correct one is already present there, even if
> the Internet as a whole insists on presenting it as the
> Razer Sabertooth Elite, which (by all accounts) is not:
> 
> { 0x1689, 0xfe00, "Razer Sabertooth", 0, XTYPE_XBOX360 },
> 
> That's it. No other functional changes intended.
> 
> Fixes: f554f619b70 ("Input: xpad - sync device IDs with xboxdrv")
> Signed-off-by: Ismael Ferreras Morezuelas <swyterzone@gmail.com>
> ---
>  drivers/input/joystick/xpad.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index c77cdb3b62b5..1510438c5578 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
> @@ -249,7 +249,6 @@ static const struct xpad_device {
>  	{ 0x1430, 0x8888, "TX6500+ Dance Pad (first generation)", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
>  	{ 0x1430, 0xf801, "RedOctane Controller", 0, XTYPE_XBOX360 },
>  	{ 0x146b, 0x0601, "BigBen Interactive XBOX 360 Controller", 0, XTYPE_XBOX360 },
> -	{ 0x1532, 0x0037, "Razer Sabertooth", 0, XTYPE_XBOX360 },
>  	{ 0x1532, 0x0a00, "Razer Atrox Arcade Stick", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOXONE },
>  	{ 0x1532, 0x0a03, "Razer Wildcat", 0, XTYPE_XBOXONE },
>  	{ 0x15e4, 0x3f00, "Power A Mini Pro Elite", 0, XTYPE_XBOX360 },
> 

The list here doesn't actually affect which devices that xpad will attach to.
xpad_table[] is what determines the devices that xpad's probe() will be
called for. It does this using the VID + vendor-defined interface subclass
and interface number, not the VID+PID combos. xpad_device[] just provides a
friendly name and quirk flags for some supported gamepads. Gamepads that
aren't in the list will just show up as "Generic X-Box pad" with no quirk
flags applied.

If 1532:0037 is actually a mouse, it's unlikely we'd even reach the probe()
in the first place. The device would lack the expected vendor-defined Xbox
interface that is required for xpad to attach to the device.

All that said, I'm definitely not opposed to removing the entry if it isn't
a real gamepad. Given the difficulty you had finding information about this
device, I take it you don't have any 'lsusb -v' output for this device, right?

Regards,
Cameron
Ismael Ferreras Morezuelas July 31, 2020, 6:14 a.m. UTC | #2
On 31/07/2020 7:54, Cameron Gutman wrote:
> On 7/30/20 8:44 AM, Ismael Ferreras Morezuelas wrote:
>> -	{ 0x1532, 0x0037, "Razer Sabertooth", 0, XTYPE_XBOX360 },
>>
> 
> The list here doesn't actually affect which devices that xpad will attach to.
> xpad_table[] is what determines the devices that xpad's probe() will be
> called for. It does this using the VID + vendor-defined interface subclass
> and interface number, not the VID+PID combos. xpad_device[] just provides a
> friendly name and quirk flags for some supported gamepads. Gamepads that
> aren't in the list will just show up as "Generic X-Box pad" with no quirk
> flags applied.
> 
> If 1532:0037 is actually a mouse, it's unlikely we'd even reach the probe()
> in the first place. The device would lack the expected vendor-defined Xbox
> interface that is required for xpad to attach to the device.
> 
> All that said, I'm definitely not opposed to removing the entry if it isn't
> a real gamepad. Given the difficulty you had finding information about this
> device, I take it you don't have any 'lsusb -v' output for this device, right?
> 
> Regards,
> Cameron
> 

Hi, Cameron. Yeah, the main idea is to clean the list, even if as you say it hasn't
caused mouse issues and that's why probably nobody has noticed it before.

Because, for some reason, everyone assumes some kind of correctness even when most of
these are community-sourced and self-reported, everyone copies these lists from
somewhere else. Hopefully the fixes will trickle downstream.

So yeah, I know for sure that (for example) the internal list Valve uses comes right from here:
https://hg.libsdl.org/SDL/file/7d94464f10f7/src/joystick/controller_type.h#l246

(It's commented out)

Actual change referencing this kernel issue:
https://hg.libsdl.org/SDL/rev/29809f6f0271

For more information of the device, take a look here:
https://github.com/xboxdrv/xboxdrv/pull/59

You can see a lsusb dump here: https://github.com/xboxdrv/xboxdrv/files/76581/Qa6dBcrv.txt

So yeah, let me know what you guys think. This has been a weird tangent for me. :)
Cameron Gutman Aug. 2, 2020, 10:50 p.m. UTC | #3
On 7/30/20 11:14 PM, Swyter wrote:
> On 31/07/2020 7:54, Cameron Gutman wrote:
>> On 7/30/20 8:44 AM, Ismael Ferreras Morezuelas wrote:
>>> -	{ 0x1532, 0x0037, "Razer Sabertooth", 0, XTYPE_XBOX360 },
>>>
>>
>> The list here doesn't actually affect which devices that xpad will attach to.
>> xpad_table[] is what determines the devices that xpad's probe() will be
>> called for. It does this using the VID + vendor-defined interface subclass
>> and interface number, not the VID+PID combos. xpad_device[] just provides a
>> friendly name and quirk flags for some supported gamepads. Gamepads that
>> aren't in the list will just show up as "Generic X-Box pad" with no quirk
>> flags applied.
>>
>> If 1532:0037 is actually a mouse, it's unlikely we'd even reach the probe()
>> in the first place. The device would lack the expected vendor-defined Xbox
>> interface that is required for xpad to attach to the device.
>>
>> All that said, I'm definitely not opposed to removing the entry if it isn't
>> a real gamepad. Given the difficulty you had finding information about this
>> device, I take it you don't have any 'lsusb -v' output for this device, right?
>>
>> Regards,
>> Cameron
>>
> 
> Hi, Cameron. Yeah, the main idea is to clean the list, even if as you say it hasn't
> caused mouse issues and that's why probably nobody has noticed it before.
> 
> Because, for some reason, everyone assumes some kind of correctness even when most of
> these are community-sourced and self-reported, everyone copies these lists from
> somewhere else. Hopefully the fixes will trickle downstream.
> 
> So yeah, I know for sure that (for example) the internal list Valve uses comes right from here:
> https://hg.libsdl.org/SDL/file/7d94464f10f7/src/joystick/controller_type.h#l246
> 
> (It's commented out)
> 
> Actual change referencing this kernel issue:
> https://hg.libsdl.org/SDL/rev/29809f6f0271
> 
> For more information of the device, take a look here:
> https://github.com/xboxdrv/xboxdrv/pull/59
> 
> You can see a lsusb dump here: https://github.com/xboxdrv/xboxdrv/files/76581/Qa6dBcrv.txt
> 
> So yeah, let me know what you guys think. This has been a weird tangent for me. :)
> 

Yep, that device definitely isn't an Xbox controller. That's for sure.

We wouldn't reach xpad_probe(), but it's a good idea to get rid of it anyway
to ensure that other projects using the our list won't be misled like SDL was.

On the off chance Razer did release an Xbox gamepad with that VID/PID, we'll
still enumerate it properly in xpad using the generic controller codepath.

So this patch looks good to me.

Reviewed-by: Cameron Gutman <aicommander@gmail.com>


Regards,
Cameron
diff mbox series

Patch

diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index c77cdb3b62b5..1510438c5578 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -249,7 +249,6 @@  static const struct xpad_device {
 	{ 0x1430, 0x8888, "TX6500+ Dance Pad (first generation)", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
 	{ 0x1430, 0xf801, "RedOctane Controller", 0, XTYPE_XBOX360 },
 	{ 0x146b, 0x0601, "BigBen Interactive XBOX 360 Controller", 0, XTYPE_XBOX360 },
-	{ 0x1532, 0x0037, "Razer Sabertooth", 0, XTYPE_XBOX360 },
 	{ 0x1532, 0x0a00, "Razer Atrox Arcade Stick", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOXONE },
 	{ 0x1532, 0x0a03, "Razer Wildcat", 0, XTYPE_XBOXONE },
 	{ 0x15e4, 0x3f00, "Power A Mini Pro Elite", 0, XTYPE_XBOX360 },