Reproduced on Bazzite, desktop version.

Update: debugging with xev

Environment

• OS: Ubuntu 26.04 (fully up to date)
• Steam client: beta version 1782437068

Test protocol

Button configuration (Desktop Configuration in Steam client):

Steps:

1. Used the Steam client to configure the buttons in Desktop Configuration mode as described above.
2. Launched xev and focused its window.
3. Pressed each button on the controller and recorded the resulting X11 events from the log.

Raw xev output

Button A — bound to . (QWERTY dot):

KeyPress event, serial 38, synthetic NO, window 0x3200001,
    root 0x350, subw 0x0, time 235928, (-418,-5), root:(1291,69),
    state 0x10, keycode 59 (keysym 0x3b, semicolon), same_screen YES,
    XLookupString gives 1 bytes: (3b) ";"
    XmbLookupString gives 1 bytes: (3b) ";"
    XFilterEvent returns: False
KeyRelease event, serial 38, synthetic NO, window 0x3200001,
    root 0x350, subw 0x0, time 235972, (-418,-5), root:(1291,69),
    state 0x10, keycode 59 (keysym 0x3b, semicolon), same_screen YES,
    XLookupString gives 1 bytes: (3b) ";"
    XFilterEvent returns: False

Button B — bound to ; (QWERTY semicolon):

KeyPress event, serial 38, synthetic NO, window 0x3200001,
    root 0x350, subw 0x0, time 298564, (36,-28), root:(1745,46),
    state 0x10, keycode 59 (keysym 0x3b, semicolon), same_screen YES,
    XLookupString gives 1 bytes: (3b) ";"
    XmbLookupString gives 1 bytes: (3b) ";"
    XFilterEvent returns: False
KeyRelease event, serial 38, synthetic NO, window 0x3200001,
    root 0x350, subw 0x0, time 298616, (36,-28), root:(1745,46),
    state 0x10, keycode 59 (keysym 0x3b, semicolon), same_screen YES,
    XLookupString gives 1 bytes: (3b) ";"
    XFilterEvent returns: False

Button X — bound to 1:

KeyPress event, serial 38, synthetic NO, window 0x3200001,
    root 0x350, subw 0x0, time 325870, (41,-26), root:(1750,48),
    state 0x10, keycode 10 (keysym 0x26, ampersand), same_screen YES,
    XLookupString gives 1 bytes: (26) "&"
    XmbLookupString gives 1 bytes: (26) "&"
    XFilterEvent returns: False
KeyRelease event, serial 38, synthetic NO, window 0x3200001,
    root 0x350, subw 0x0, time 325926, (41,-26), root:(1750,48),
    state 0x10, keycode 10 (keysym 0x26, ampersand), same_screen YES,
    XLookupString gives 1 bytes: (26) "&"
    XFilterEvent returns: False

Button Y — bound to Q:

KeyPress event, serial 38, synthetic NO, window 0x3200001,
    root 0x350, subw 0x0, time 350103, (40,-25), root:(1749,49),
    state 0x10, keycode 38 (keysym 0x71, q), same_screen YES,
    XLookupString gives 1 bytes: (71) "q"
    XmbLookupString gives 1 bytes: (71) "q"
    XFilterEvent returns: False
KeyRelease event, serial 38, synthetic NO, window 0x3200001,
    root 0x350, subw 0x0, time 350127, (40,-25), root:(1749,49),
    state 0x10, keycode 38 (keysym 0x71, q), same_screen YES,
    XLookupString gives 1 bytes: (71) "q"
    XFilterEvent returns: False

Analysis

Steam Input injects the QWERTY keycode of the bound key, regardless of the system keyboard layout. XKB then correctly translates that keycode — but since the keycode is wrong to begin with, the output character is wrong too.

For button X (working): the 1 key happens to sit at the same physical position in both QWERTY and AZERTY. The keycode (10) is correct and XKB produces the expected &.

For buttons A and B (collision): both . and ; map to keycode 59 in QWERTY, so Steam Input injects the same keycode for both, making it impossible to distinguish them — and impossible to produce the expected AZERTY characters : and m.

For button Y: Steam Input injects keycode 38 (QWERTY Q), which XKB correctly translates to q under AZERTY — but the expected output is a, which sits at that physical position on an AZERTY keyboard.

Below is the complete mapping table for all available Steam Input key bindings, showing the expected AZERTY keycode and the actually injected keycode, along with the resulting character where applicable. Rows marked ✅ are correct, rows marked ❌ are incorrect.

Root cause analysis

From this data, the mechanism behind the bug seems clear. For each binding, Steam Input:

1. Takes the character shown on the QWERTY key (e.g. Q, [, \)
2. Searches the active system layout (AZERTY) for the key that produces that character, including characters that require a modifier combination (Shift, AltGr)
3. Extracts the keycode of that key
4. Injects that keycode via uinput
5. XKB then translates it normally, producing the base character of that key in AZERTY

This explains almost every incorrect mapping. Here are the detailed cases:

Keycode 24 — QWERTY Q
Steam Input looks up Q in the AZERTY layout and finds it on keycode 38 (the A key). It injects keycode 38 → XKB produces q. Expected: a.

Keycode 25 — QWERTY W
Steam Input looks up W in the AZERTY layout and finds it on keycode 52 (the Z key). It injects keycode 52 → XKB produces w. Expected: z.

Keycode 38 — QWERTY A
Steam Input looks up A in the AZERTY layout and finds it on keycode 24 (the Q key). It injects keycode 24 → XKB produces a. Expected: q.

Keycode 52 — QWERTY Z
Steam Input looks up Z in the AZERTY layout and finds it on keycode 25 (the W key). It injects keycode 25 → XKB produces z. Expected: w.

Keycode 20 — QWERTY -
Steam Input looks up - in the AZERTY layout and finds it as the base character on keycode 15 (the 6 key), ignoring the intended keycode 20 (the ) key). It injects keycode 15 → XKB produces -. Expected: ).

Keycode 34 — QWERTY [
Steam Input looks up [ in the AZERTY layout and finds it on keycode 14 (the ( key, which produces [ when combined with AltGr). It injects keycode 14 → XKB produces (. Expected: ^.

Keycode 35 — QWERTY ]
Steam Input looks up ] in the AZERTY layout and finds it on keycode 20 (the ) key, which produces ] when combined with AltGr). It injects keycode 20 → XKB produces ). Expected: $.

Keycode 47 — QWERTY ;
Steam Input looks up ; in the AZERTY layout and finds it as the base character on keycode 59 (the . key). It injects keycode 59 → XKB produces ;. Expected: m.

Keycode 48 — QWERTY '
Steam Input looks up ' in the AZERTY layout and finds it as the base character on keycode 13 (the 4 key). It injects keycode 13 → XKB produces '. Expected: ù.

Keycode 51 — QWERTY \
Steam Input looks up \ in the AZERTY layout and finds it on keycode 17 (the 8 key, which produces \ when combined with AltGr). It injects keycode 17 → XKB produces _. Expected: *.

Keycode 58 — QWERTY M
Steam Input looks up m in the AZERTY layout and finds it as the base character on keycode 47. It injects keycode 47 → XKB produces m. Expected: ,.

Keycode 61 — QWERTY /
Steam Input looks up / in the AZERTY layout and finds it on keycode 60 (the : key, which produces / when combined with Shift). It injects keycode 60 → XKB produces :. Expected: !.

Two additional cases fall outside this pattern:

Keycode 49 — QWERTY `
Following the same mechanism, Steam Input should look up ` in the AZERTY layout, find it via AltGr+è (keycode 16), and inject keycode 16 → XKB would produce è. Instead, Steam Input injects keycode 33 (the P key) → XKB produces p. The expected fallback behavior does not occur, and the result has no obvious logic.

Keycode 91 — Numpad .
Steam Input injects keycode 129 instead of 91. Despite this, XKB correctly produces ., so the character output is correct. However, the use of a non-standard keycode for this key remains unexplained.

One additional case is worth noting separately:

Keycode 108 — RAlt
Steam Input produces no event at all.