evemu-describe output for the devices that xpadneo supports

[kakra]

Originally posted in https://github.com/atar-axis/xpadneo/issues/428#issuecomment-1591720366

@smcv wrote:

Unfortunately, evdev doesn't give us enough information to distinguish between devices that we really should be able to distinguish - a prominent example is that a 3-axis accelerometer like the one in the Wii Remote is indistinguishable from a set of 3 driving-simulator pedals - so that is not going to be the full answer. "Most" gamepads have sensible evdev mappings, but many don't. We're collecting test data in SDL's test/testevdev.c, currently only used for testing the "is this a joystick?" heuristic, but in future I'd like to use that same test data to assert that we default to the desired mappings as well.

To be able to do that, it would be really, really useful to have full evemu-describe output for the devices that xpadneo supports.

[...]

One issue for the whole batch (which we can close when the test data has been added), with one comment per physical device, is probably a good way to organise them.

I have the following devices on my desk and can create such data:

• [x] Xbox One S Wireless controller
• [ ] Xbox Elite Series 2 controller
• [ ] Xbox Series S controller
• [ ] GuliKit KingKong Pro 2 Wireless controller
• [ ] 8Bitdo Pro 2 Wireless controller

[kakra]

You can report it here. :)

Yeah, that last line should not have gone into the text... I removed it now. ;-)

[slouken]

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.

[smcv]

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: https://github.com/libsdl-org/SDL/issues/7801#issuecomment-1840788253

Or, if you don't have Steam, the output of evemu-describe and od -t x1 /sys/class/input/event${N}/device/device/report_descriptor for each device is the next best thing.

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.

[kakra]

I can use the Steam tool to provide the data. Maybe we should re-open this then? @slouken

[slouken]

Sure

[kakra]

I'll add more models later:

1. xpadneo 0.9.x with Xbox One S controller: xpadneo-0.9-xb1s.json

[slouken]

@smcv, can you create a PR with what you need from this data, if it's useful?

[smcv]

      "raw_keys" : [
        "0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
        "0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
        "0x00, 0x00, 0x00, 0x00, 0x80, 0x00, 0x00, 0x00,",
        "0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
        "0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xdb, 0x7c,",
        "0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
        "0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
        "0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
        "0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
        "0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
        "0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
        "0x00, 0x00, 0x00, 0x00, 0xf0, 0x00, 0x00, 0x00,"
      ],

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?

[smcv]

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?

[smcv]

Ah, I see from https://github.com/kakra/xpadneo/commit/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).

[kakra]

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?

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.

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).

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. dmesg -w will show you that the profile was changed.

Also, the ABS_MISC axis is a deprecated axis reporting (rz - z).

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.

[kakra]

@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.