Linux-Doc Archive on
 help / color / Atom feed
From: Cameron Gutman <>
To: Swyter <>,
	Dmitry Torokhov <>
Cc:, Jonathan Corbet <>,
Subject: Re: [PATCH] Input: xpad: Spelling fixes for "Xbox", improve and proofread the listed xpad device names
Date: Sun, 2 Aug 2020 16:41:35 -0700
Message-ID: <> (raw)
In-Reply-To: <>

On 7/30/20 11:54 PM, Swyter wrote:
> On 31/07/2020 8:33, Cameron Gutman wrote:
>>> While doing my research I also noticed that the 1532:0037 VID/PID seems to
>>> be used by the DeathAdder 2013, so that Razer Sabertooth instance looks
>>> wrong and very suspect to me, I created a separate patch for that.
>> The above sentence probably doesn't belong in the commit message.
> Fair enough, I should probably turn that into "reviewer" notes.
> I think I mentioned it because I didn't update that bad entry.
> Thinking it would be deleted soon. But good point.
>> The docs and comment changes look fine to me.
> Great, I was a bit wary about this.
>> I'm somewhat concerned about the possibility of breaking userspace by changing
>> names. Some programs' gamepad mappings may be dependent on matching the device
>> names, rather than the VID+PID.
>> For example, Android did not expose the VID and PID for input devices until
>> Android 4.4. The device name was the only available attribute for matching
>> gamepads from Android 2.3 to 4.3. While these ancient Android version will
>> almost certainly never run a kernel with this patch, I worry about the
>> possibility of apps that haven't moved to VID+PID matching (and not just for
>> Android; I don't know if other libraries or frameworks have/had similar
>> limitations).
>> Perhaps my concerns are overblown, but If we aren't worried about changing
>> names, I'd really prefer to just drop the hardcoded names entirely and use the
>> manufacturer and product strings provided in the USB string descriptors. The
>> device list would turn into a quirk list where only device entries with a
>> special mapping flag like MAP_DPAD_TO_BUTTONS or MAP_TRIGGERS_TO_BUTTONS would
>> remain, and the device name strings would just become comments on each quirk
>> entry.
>> Thoughts?
>> Regards,
>> Cameron
> I don't doubt that changing some names will break some basic rule matching.
> But given that the kernel nomenclature is so inconsistent, I think anyone searching
> for "X-Box" and five other variants will also have to search for the actual "Xbox",
> or at least I hope so. Keep in mind that I have tried to make each overhauled entry
> *more* detailed when possible. So now each model has extra information (mainly
> manufacturer and button-layout type) instead only some vague/informal model name.
> SDL2 and Unity abstract these things a bit. I actually implement similar strings
> checks in my own game/engine as fallback and it's exactly what I ended up doing.
> I generally don't trust device strings, they'll be less detailed than these.
> A good bunch of those are unlicensed, so they'll be wrong or missing.
> Let me know what you think.

I agree that the changes look like an improvement. I also doubt that we'll ever
be able to prove definitively that there aren't programs out that taking a
dependency on the exact names of the gamepads in the list.

I guess one could also make the argument that adding a gamepad to this list
would have the same effect of possibly breaking userspace programs that used to
identify it via the "Generic X-box Pad" string. Those programs would need to
have the flexibility to handle receiving the generic name or a specific name
from our list, so maybe they're already robust enough to handle not matching on
one of the names they're expecting.

Dmitry, what are your thoughts about possible userspace breakage from updating
input device names? Has a similar change been done successfully before?


      reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-30 19:06 Ismael Ferreras Morezuelas
2020-07-31  6:33 ` Cameron Gutman
2020-07-31  6:54   ` Swyter
2020-08-02 23:41     ` Cameron Gutman [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Doc Archive on

Archives are clonable:
	git clone --mirror linux-doc/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-doc linux-doc/ \
	public-inbox-index linux-doc

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone