linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Cameron Gutman <aicommander@gmail.com>
To: Benjamin Valentin <benpicco@googlemail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	linux-input@vger.kernel.org, Lee Jones <lee.jones@linaro.org>
Subject: Re: Input: xpad - add more Xbox one controller IDs
Date: Sun, 14 Nov 2021 15:05:09 -0600	[thread overview]
Message-ID: <54fa069f-987a-371f-3ef4-51198aed219f@gmail.com> (raw)
In-Reply-To: <20211114205122.575567c6@rechenknecht2k11>

On 11/14/21 13:51, Benjamin Valentin wrote:
> On Sat, 13 Nov 2021 19:34:54 -0600
> Cameron Gutman <aicommander@gmail.com> wrote:
> 
>> For 1, the way Windows does it is via the Microsoft OS descriptor [0].
>> AFAIK, the specific OS descriptor strings are "XUSB20" for Xbox 360
>> and "XGIP10" for Xbox One.
>>
>> That functionality is handled by xpad_table[] and the
>> bInterfaceProtocol detection logic in xpad_probe(). The xpad_device[]
>> entry isn't required for detection or functionality of devices,
>> unless those devices need special treatment like
>> MAP_TRIGGERS_TO_BUTTONS or something.
> 
> The problem is that the gamepad then gets assigned the type
> XTYPE_UNKNOWN which excludes it from all run-time code path switches.
> 
> E.g. if I comment out
> 
> //    { 0x045e, 0x028e, "Microsoft X-Box 360 pad", 0, XTYPE_XBOX360 },
> 
> my X-Box 360 pad will not only lose any LED or rumble support, it will
> also not report any input events with jstest because
> xpad360_process_packet() is no longer called.
> 

XTYPE_UNKNOWN is a special value that should always be overridden by
the check in xpad_probe() to be the proper XTYPE value at runtime:

	if (xpad->xtype == XTYPE_UNKNOWN) {
		if (intf->cur_altsetting->desc.bInterfaceClass == USB_CLASS_VENDOR_SPEC) {
			if (intf->cur_altsetting->desc.bInterfaceProtocol == 129)
				xpad->xtype = XTYPE_XBOX360W;
			else if (intf->cur_altsetting->desc.bInterfaceProtocol == 208)
				xpad->xtype = XTYPE_XBOXONE;
			else
				xpad->xtype = XTYPE_XBOX360;
		} else {
			xpad->xtype = XTYPE_XBOX;
		}

	...


Those values should definitely be correct, because they're what we
use in the xpad_table[] itself. If they don't match, xpad_probe()
won't get called at all.

Can you see what's going on in xpad_probe() when you comment out
that line for your gamepad?

> I'll try to check on how to read out the OS descriptor string, maybe
> that allows us to detect the type on init and provide a better default
> experience.

That type derivation code above already handles determining the type for
unknown gamepads (assuming it actually works). The problem is having to
maintain the xpad_table[] list with every vendor that produces an Xbox
gamepad. That's where an extension to usb_device_id and something like
a USB_MS_OS_DESCRIPTOR("XUSB20") macro would come in, if the USB core
had first-class support for Microsoft OS descriptors.

The problem is that adding that Microsoft OS descriptor query may cause
compatibility issues for other devices. Windows actually keeps track of
whether the OS descriptor query fails to avoid querying it again [0].

[0]: https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/microsoft-defined-usb-descriptors

> 
> Best,
> Benjamin
> 

Regards,
Cameron

      parent reply	other threads:[~2021-11-14 21:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-13 12:17 Input: xpad - add more Xbox one controller IDs Benjamin Valentin
2021-11-13 12:20 ` [PATCH] Input: xpad - remove 'rumble support' from TODO Benjamin Valentin
2021-11-14  1:34 ` Input: xpad - add more Xbox one controller IDs Cameron Gutman
2021-11-14 19:51   ` Benjamin Valentin
2021-11-14 20:37     ` Benjamin Valentin
2021-11-14 21:14       ` Cameron Gutman
2021-11-16 15:52         ` Benjamin Valentin
2021-11-14 21:05     ` 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=54fa069f-987a-371f-3ef4-51198aed219f@gmail.com \
    --to=aicommander@gmail.com \
    --cc=benpicco@googlemail.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-input@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).