evemu-describe output for the devices that xpadneo supports #7823
Comments
Yeah, that last line should not have gone into the text... I removed it now. ;-) |
|
SDL 2.0 is now in maintenance mode, and all inactive issues are being closed. If this issue is impacting you, please feel free to reopen it with additional information. |
|
This particular issue report is still equally relevant for SDL 3, but needs more information from the issue submitter in order to be useful. @kakra, if you happen to have Steam installed on a device that you can plug these controllers into, please see: #7801 (comment) Or, if you don't have Steam, the output of In the case of devices that have both in-kernel and out-of-tree drivers (like xpad vs. xpadneo), please specify which driver and which driver version you used - it would be even better if you can collect the same information with each driver, if different. |
|
I can use the Steam tool to provide the data. Maybe we should re-open this then? @slouken |
|
Sure |
|
I'll add more models later:
|
|
@smcv, can you create a PR with what you need from this data, if it's useful? |
This surprises me. Is this driver working as intended? As expected, the 5th row is the same as an X-Box 360 controller, or equivalently an X-Box One S controller via the official kernel driver: it ends with 0xdb 0x7c, which is the basic button functionality of an Xbox-style controller (face buttons, shoulder buttons and clickable thumbsticks, but no D-pad or triggers, because those are represented as axes instead). The last row is the only other one that is not all-zeroes. After the discussion on atar-axis/xpadneo#428, I had expected that it would be the same as #7814's data for the X-Box One Elite 2 via USB, using BTN_TRIGGER_HAPPY5 up to BTN_TRIGGER_HAPPY8 inclusive for the back buttons (paddles), which would mean the first byte of the last row would be 0xf0. But instead, it seems to be using BTN_TRIGGER_HAPPY33 up to BTN_TRIGGER_HAPPY36 inclusive. Is that correct? Is that intended functionality? |
|
The other thing that surprises me here is that when compared with an X-Box One S controller seen via the kernel's own driver, it reports an extra axis, ABS_MISC. Does this correspond to a physical feature of the controller? |
|
Ah, I see from kakra/xpadneo@e641e48e that xpadneo is using TRIGGER_HAPPY33..36 to represent swappable profiles; and this gamepad doesn't physically have back buttons (paddles). Also, the ABS_MISC axis is a deprecated axis reporting (rz - z). |
This is an out-of-tree driver providing an alternative interface to X-Box gamepads. Compared with the in-kernel driver, it adds four pseudo-buttons used to indicate which profile is active, and an optional "misc" axis that combines the two triggers into a rudder. Partially addresses libsdl-org#7823 Signed-off-by: Simon McVittie <[email protected]>
This is an out-of-tree driver providing an alternative interface to X-Box gamepads. Compared with the in-kernel driver, it adds four pseudo-buttons used to indicate which profile is active, and an optional "misc" axis that combines the two triggers into a rudder. Partially addresses libsdl-org#7823 Thanks: @kakra Signed-off-by: Simon McVittie <[email protected]>
This is an out-of-tree driver providing an alternative interface to X-Box gamepads. Compared with the in-kernel driver, it adds four pseudo-buttons used to indicate which profile is active, and an optional "misc" axis that combines the two triggers into a rudder. Partially addresses #7823 Thanks: @kakra Signed-off-by: Simon McVittie <[email protected]>
I don't currently know which mapping we are using for the paddles because we are in the dev-cycle for v0.10 but the plan is to move the paddles to the same positions as the in-kernel xpad driver does (it's probably that way already but I'd need to look into the source code). That's why I didn't submit XBE2 mappings yet.
Yes, correct. I moved it to the end so we don't have to shift that around when we add new buttons which in-kernel xpad adds. I'm still not sure if I'm going to implement that as a HID dial instead - because it's really only that: A virtual dial to switch between exactly four positions. So position 33-36 may go away. But that should not hurt if they go missing from SDL: They just won't report presses then. You can test this even with an XB1S controller by pressing and holding the Guide button (like a shift key) and then hitting A,B,X,Y.
Equally correct. It will be completely removed in the next version cycle because it causes problems with some input mappers in games. Maybe SDL should just ignore it to not create the same issues. |
|
@smcv BTW, maybe of interest: In profile 0, the back paddles are hard-coded to buttons A,B,X,Y - so if profile 0 bit is set, you may want to ignore presses on the paddles (xpadneo may already filter that out). Profiles 1-3 can be programmed to send (possibly any) HID report, at least early firmware versions had a programming HID report but it's gone in later versions, even the RGB interface is gone (the Guide LED can actually show different colors). So I think we are going to emulate that in the HID driver. But I think GIP mode (which in-kernel xpad uses but doesn't expose) can still control the LED and the programming interface. I still didn't try what a reprogrammed profile 1-3 does in xpadneo but some users confirmed that profiles are stored in the hardware. |
Originally posted in atar-axis/xpadneo#428 (comment)
@smcv wrote:
I have the following devices on my desk and can create such data:
The text was updated successfully, but these errors were encountered: