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