XInput and HID - architecture

[Juan Jose Gonzalez]

On 03/03/2016 07:04 PM, Juan Jose Gonzalez wrote:
> On 03/03/2016 06:33 PM, Aric Stewart wrote:
>> On 3/3/16 9:10 AM, Juan Jose Gonzalez wrote:
>>> The axis/button mappings themselves are pretty easy to do with simple
>>> registry keys. The matching mechanism, however, is more complex. VID/PID
>>> isn't enough here, since the same VID and PID might need completely
>>> different mappings depending on which system you are on and even which
>>> driver you are using to emulate a HID device from an xbox controller.
>>> I've implemented a hierarchical structure which allows composite matches
>>> like the following:
>>> AND(VID = 0x45e, OR(PID = 0x28e, PID = ...), OR(Version = 0x110, ...),
>>> OR(NAME="Microsoft X-Box 360 pad", NAME="Microsoft X-Box 360 wireless
>>> pad"), HASUSAGE(0x01, 0x09, 0x30), ...)).
>>> Storing that in the registry in clear text is doable, but it seems like
>>> a bit of overhead to fill the registry with that. On the other hand, I
>>> have to admit it also feels weird to store configs as binary blobs in
>>> the registry
>> Shouldn't VID and PID uniquely identify a device?  Do companies reuse PID values frequently enough that we have to worry about that? 
>>
>> Now I know from Linux Input it can be hard/impossible to get the device VID and PID, if we ask for it we get things like 0001 and 0002. So having an alternate match, maybe on device name, would be needed.
> At the USB level, VID and PID [should] uniquely identify any xbox
> controller. The problem is that we're using drivers to simulate HID
> devices from those xbox controllers. Those devices don't officially
> exist as such, so the manufacturers are not recycling their PIDs, we
> are. On my machine, using xboxdrv, I am getting VID=0x045e and
> PID=0x028e for a controller mapped with "--mimic-xpad". I don't know if
> the PID actually matches a XBox 360 wired controller, but the VID is
> definitely Microsoft's. Basically, we're getting the same VID and PID,
> even though its probably a completely different device (when you look at
> its capabilities) than what an OSX HID driver would generate. Therefore,
> the matching logic needs to be able to check other factors, like which
> capabilities are reported or whether some string descriptor is
> available. I'm not sure this can be condensed into one flat "ANDed" line.
>
What do you think having the winehidminidriver.sys evdev backend add the
suffix " (evdev)" to the device name? This would allow us to easily
identify the devices later on (in xinput and elsewhere). As I mentioned
before, we're simulating new devices anyway, not passing original HID
devices through, so altering the descriptors is justifiable.
The only problem I see with this approach is the string length. I assume
that the code issuing the IOCTL to the HID driver provides a buffer that
exactly fits the 255 character maximum of HID. If we want to add a
suffix, we'd have to reduce the amount of characters returned from the
original device, possibly cutting the string (although I doubt any real
device will have a 255 character long name).

- Juan