Which evdev key event does Steam watch for launching / tenfoot?

[kakra]

While working on atar-axis/xpadneo#158 we came across the question if Steam only watches for the EV_KEY / KEY_HOME event which can also be grabbed by browsers, or if it looks for other key events, too.

Which key events can be used to bring up the Steam client, its tenfoot launcher or the Steam overlay?

[kakra]

@kisak-valve Any updates on this? Is there some documentation on global hotkeys for the Steam client?

[mercuriete]

@kakra
Not sure if this is useful for you but apart from an Xbox Elite 2 I have a dual shock 4.
the evtest report this for my DS4:

Event: time 1591750515.893615, type 1 (EV_KEY), code 316 (BTN_MODE), value 1
Event: time 1591750516.025290, type 1 (EV_KEY), code 316 (BTN_MODE), value 0

This button doesn't open the home on a browser but it does open the steam big picture.

Hope it help you.

EDIT: the DS4 is a hid device with some quircks, the module is called: hid_sony.
EDIT2: you can see the mapping of the button somewhere near here: https://github.com/torvalds/linux/blob/master/drivers/hid/hid-sony.c#L412

[kakra]

Thanks... This is strange because in my tests BTN_MODE didn't open the Steam client... I'll try again.

[kakra]

I tried changing the xpadneo driver to send BTN_MODE again what immediately showed the problem of this: The Linux event system inserts the button before the thumb stick buttons, resulting in user space seeing 11 buttons, and some games and the legacy JS API seeing the wrong button order: Now, the BTN_MODE event does nothing, but BTN_THUMBR fires up Steam. Even when I fixup the HID reports to swap bits around for the buttons or patch the reported event IDs, this is messed up. The only way to fix it, is to expose only 10 buttons to user space. Looking at the HID descriptor table, the Xbox button isn't even meant to be exposed as a joystick button, the original protocol says Usage (AC Home) (Linux) and Usage (Sys Control) (Windows) so it's not part of the button map.

I think this is due to the kernel defining the following keycode order:

#define BTN_SELECT		0x13a
#define BTN_START		0x13b
#define BTN_MODE		0x13c
#define BTN_THUMBL		0x13d
#define BTN_THUMBR		0x13e

Thus, mode becomes inserted before the others. OTOH, this strange behavior was exposed only after updating the controller firmware, and I ended up fixing it in xpadneo by just patching the HID reports and HID descriptor, and all applications (even legacy JS API) worked correctly again but only when I limited this to 10 buttons. Do 11 buttons and it's a mess again.

The HID keycode map of Linux has a lot of flaws, i.e. defining BTN_Y as BTN_WEST although I know no controller which has it on the left side of the diamond (except maybe old Nintendo controllers which it seems to be based on, IMHO using cardinal directions should have never been part of the Linux HID definitions). The legacy joystick API does its own thing altogether (it maps whatever there is in order of keycode / axiscode value, and almost all games rely on that even when using the event layer, especially games running in Wine). It's a mess. Violating the Linux HID API definition while programming a driver is the only way to make user space happy without going through fixups in other layers like SDL. This works reliably for games using the legacy API, games going through SDL mappings, games in Wine using dinput or xinput, games reading HID descriptors and raw HID reports, Chrome's gamepad API... xpadneo only needs to take care not matching on an already existing SDL mapping otherwise it's messed up again (this is done by changing the HID version number).

Back to my original intention of this topic: I wanted to maybe find a better key to expose to user space (a real keycode, not a button) so we do not conflict with browsers.

[mercuriete]

@kakra
I am so sorry that that idea didn't helps you.
Congratulation for your amazing work on xpadneo
I hope valve team aproaches you to improve compatibility with xbox controllers.

Good Luck! 👍