Re: [PATCH] xpad: expose xinput capabilities via sysattr

On Wed, Mar 4, 2026 at 2:34 PM Dmitry Torokhov
[off-list ref] wrote:

You need to start with enumerating what data is currently not available
through other means and why it is needed. Is this something that other
gamepad-like devices also lack?

Other controllers do have this sort of thing though, PS4 and PS5
controllers have a capabilities report, but since they are HID based,
SDL just requests the report directly via a hid get feature report
request.
Since xinput isn't HID based, there isn't a way to fetch these
reports, and right now that makes it difficult to discern these
devices in SDL and Wine.
Usually you could also fall back and rely on vids and pids, but 360
wireless devices don't include pids anywhere, so that isn't a usable
method here.
The only other devices I can think of that would have similar problems
would be the Xbox One controllers, but at least there we do have a
workable vid and pid, so we can just rely on that since the descriptor
format is much more complicated in that scenario.

If it was prefered, we could go some route where we put the entire
capabilities blob into a single sysattr as JSON or something, which is
similar to the route unity went with for this sort of thing, or if
there is some way to request data in a similar fashion to how HID has
feature reports, i'd be happy to just implement some sort of
capabilities request, I just didn't see a way to do that when i was
trying to implement this.

On Wed, Mar 4, 2026 at 2:46 PM Sanjay Govind [off-list ref] wrote:

On Wed, Mar 4, 2026 at 2:34 PM Dmitry Torokhov [off-list ref] wrote:

quoted

You need to start with enumerating what data is currently not available
through other means and why it is needed. Is this something that other
gamepad-like devices also lack?

This information in particular is important for xinput specifically, as it gives context for determining what kind of controller is in use.
For most other gamepads, that was done via the vid and pid, but for xinput that isn't enough as the vid and pid isn't exposed over wireless.
XInput also just doesn't expose the vid and pid on windows, so a lot of controllers encode information into the other capabilities like the sticks,
and the flags, so you need the entire capabilities blob to properly differentiate every controller, and my goal is to then feed this into Wine and SDL,
so that they can properly differentiate these controllers.

On Wed, Mar 4, 2026 at 2:34 PM Dmitry Torokhov
[off-list ref] wrote:

You need to start with enumerating what data is currently not available
through other means and why it is needed. Is this something that other
gamepad-like devices also lack?

Thinking about this some more, I think what I'm really after is just a
generic way for an app to request a vendor-defined report from a
controller, so that libraries like SDL can better request the
capabilities of a device when trying to handle devices properly. As it
stands, PS4, PS5, OG Xbox, Xbox 360 and Xbox One all have vendor
defined reports that can be fetched for describing controller
information, but only PS4 and PS5 actually even give something like
SDL the ability to fetch that data right now because they can just do
hid feature report reads to get it, while the Xbox controllers don't
use HID and thus we need to expose that from the input layer.