HIDAPI failing to set GUID hint for some devices (Horipad Steam)

[offalynne]

In order to ensure back compatibility, devices handled by HIDAPI are supposed to have GUID data 14 set to 'h' so mappings do not conflict when passing the device filter resulting in a GUID suffix of 6800

It seems like this is not happening for (at least) the Horipad Steam controller, where mappings without the HIDAPI-indicating GUID hint are conflicting with Steam's mappings resulting in jumbled axis output

GUID Examples:

• 030000000d0f00009601000000000000
• 030000000d0f00009601000011010000
• 030000000d0f0000ab01000011010000

[slouken]

Those GUID examples look like you're not getting access to the HIDAPI driver. Can you run SDL testcontroller and see what it's outputting?

[offalynne]

Unfortunately I'm diagnosing at a distance here based on another user's report, and (obviously) lack of source access to Steam's Linux client; I don't have the device on hand to confirm the issue myself

[slouken]

Okay, it's very likely that the user has disabled hidraw access for Steam and what they're getting is the Linux HID driver instead. There isn't any mapping specified for that, so SDL is probably just querying capabilities and giving the best guess of a mapping which clearly doesn't work.

[slouken]

This is what I get on Ubuntu 20.04:

$ ./test/testcontroller
Using udev for HIDAPI joystick device discovery
HIDAPI_SetupDeviceDriver() couldn't open /dev/hidraw2: Failed to open a device with path '/dev/hidraw2': Permission denied
Added HIDAPI device 'HORI. HORIPAD STEAM' VID 0x0f0d, PID 0x01ab, bluetooth 0, version 145, serial NONE, interface 0, interface_class 0, interface_subclass 0, interface_protocol 0, usage page 0x0001, usage 0x0005, path = /dev/hidraw2, driver = NONE (DISABLED)
Using udev for joystick device discovery
Gamepad 2 added
Opened gamepad HORI. HORIPAD STEAM, guid 03004cbf0d0f0000ab01000011010000, /dev/input/event7
Player index: 0
Mapping: 03004cbf0d0f0000ab01000011010000,HORI. HORIPAD STEAM,a:b0,b:b1,x:b3,y:b4,back:b10,guide:b12,start:b11,leftstick:b13,rightstick:b14,leftshoulder:b6,rightshoulder:b7,dpup:h0.1,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,leftx:a0,lefty:a1,rightx:a2,righty:a3,lefttrigger:a5,righttrigger:a4,crc:bf4c,platform:Linux,

The HIDAPI driver isn't available and the mapping is autogenerated and works perfectly here. What mapping is used in your application?

[slouken]

Just to verify, I connected via Bluetooth as well and had the same result. I couldn't open the /dev/hidraw device so I got the autogenerated mapping and it worked correctly for all device inputs:

Mapping: 050063f60d0f00009601000091000000,HORIPAD STEAM,a:b0,b:b1,x:b3,y:b4,back:b10,guide:b12,start:b11,leftstick:b13,rightstick:b14,leftshoulder:b6,rightshoulder:b7,dpup:h0.1,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,leftx:a0,lefty:a1,rightx:a2,righty:a3,lefttrigger:a5,righttrigger:a4,crc:f663,platform:Linux,

[offalynne]

User generated the following with the GeneralArcade tool and says mappings were jumbled on Steam

030000000d0f0000ab01000011010000,HORIPAD STEAM,a:b0,b:b1,x:b3,y:b4,back:b10,guide:b12,start:b11,leftstick:b13,rightstick:b14,leftshoulder:b6,rightshoulder:b7,dpup:h0.1,dpdown:h0.0,dpleft:h0.8,dpright:h0.2,leftx:a0,lefty:a1,rightx:a2,righty:a3,lefttrigger:a5,righttrigger:a4,platform:Linux,

Unlikely to be able to test further at a distance, feel free to close unless there's any other info I can pass along

[slouken]

Hmm, the mapping they have is identical to mine, and I just verified that mine works in Steam. I'm not sure what's going on here.

[slouken]

I don't know whether this will help, but I added mappings with the extended controller functionality in cd0db8d.

[offalynne]

tangential, but would you please consider renaming the cap sense fields in the interest of legibility ? the paddle# scheme is already confusing enough, and i understand misc1-n given things like "mic" and "qam" are not shared/relatively ambiguous but left and right cap as misc5 and misc6 is a serious headache. leftcap and rightcap, perhaps ?

[slouken]

That would involve adding new buttons to the gamepad API. In general one-off capabilities of controllers aren't added a specifics to the gamepad API.

FWIW, this is the mapping Steam expects for this controller. If cap sense thumbsticks become more common, we can revisit this.

[slouken]

BTW, the logic is that the QAM button isn't equivalent to the share button on other controllers, so it's misc2, and the two new capsense buttons are misc3 and misc4. misc5 and misc6 aren't used. :)

[offalynne]

QAM button isn't equivalent to the share button on other controllers, so it's misc2

I do follow here yes, the problem is that if they have semantic meaning across mappings (eg. 'share') surely the key name should reflect this ? What's done is done for paddle andmisc1 but a bit of relief deciphering which cap is which would be appreciated since

If cap sense thumbsticks become more common

seems inevitable

[slouken]

QAM button isn't equivalent to the share button on other controllers, so it's misc2

I do follow here yes, the problem is that if they have semantic meaning across mappings (eg. 'share') surely the key name should reflect this ? What's done is done for misc and paddle but a bit of relief on deciphering which cap is which since

shrug I was just following what was done for the HIDAPI driver. The meaning of misc* buttons are always controller dependent. You shouldn't assign any specific semantic meaning to them without knowing what controller it is.

If cap sense thumbsticks become more common

seems inevitable

Possibly, and future us can revisit this then. :)