XInput and HID - architecture

[Juan Jose Gonzalez]

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.
>
> I think getting too complicated on the matching logic is not really required, we could have everything as an AND,  then we have this registry key:
>
> [HKCU/Software/wine/Xinput/mapping]
> "VID=xxx,PID=yyy"="key1"
> "VID=xxx,PID=zzz"="key1"
> "NAME=aaa"="key2"
>
> [HKCU/Software/wine/Xinput/mapping/key1]
> ...
>
> [HKCU/Software/wine/Xinput/mapping/key2]
> ...
>
> This lets OR logic be build into having multiple mapping values pointing to the same key.
Good idea!
>
> I have been thinking of this and can see the value of having a number of built in mappings also, so that many controllers work without a custom registry mapping. But we would want the registry mapping to be able to override any built in map. 
Definitely! That's what i was going for.
>> I'll implement the clear text serializer/deserializer and see how a
>> mapping looks for a real controller. I may be picturing it worse than it is.
> I feel like the logic should not be too complicated it is more a matter of identifying compatible controllers that may not match any knowing mapping. 
>
> There you would need to count buttons and axes and make sure there are enough and the right types. 
I'd rather not automatically infer mappings. I've had enough experiences
with games doing really weird stuff by assuming they know which axes are
which. I'd prefer to realize that my gamepad isn't working, go to the
control panel and create a mapping.

- Juan