XBox one Bluetooth Controller

[DigitalKrony]

This is a question more than an issue,

Is there any information on pairing and connecting the new XBox One Wireless controller released with the S?

While using bluetoothctl

• The controller is seen
• I can pair the controller
• I add it to the trust list
• When I attempt a connect to the controller, I get a bluez error.
  • there's little information other than Failed to Connect

[paroj]

echo 1 > /sys/module/bluetooth/parameters/disable_ertm

see here: https://github.com/paroj/xpad/issues/14#issuecomment-249609916

[DigitalKrony]

Brilliant. Now to get that surfaced better on a search or "How To" so it's more easily found. Thanks so much for pointing me in the right direction.

[Zsuark]

Hi everyone,

I'm using the xpad driver under linux (Linux Mint 18) - still no joy having the XBox One S controller supported. It connects temporarily, but the controller isn't recognised in steam or jstest. (Yes I've tried echo 1 > /sys/module/bluetooth/parameters/disable_ertm - which helps but no button presses or stick movements register, and the connection still drops and reconnects and drops a lot.)

If there is anything I can do to help - please let me know.

Thanks

R

[Spiffyk]

Hi, I'm having this problem on Linux Mint 18, too. I did try disable_ertm but no luck. When hooked up with a cable, it works as expected.

[terramare]

After much trial and error, my Xbox wireless controller is paired and connects to Retropie. Two things made the difference for me: 1) first connecting the controller to a Windows 10 VM vis USB and updating the firmware via the XBox Accessories app, and 2) running the echo 1 > /sys/module/bluetooth/parameters/disable_ertm command mentioned above. Now if I could just get all buttons to register in the Configure Input process in emulationstation, I'd be in business.

[terramare]

@DigitalKrony Is your Xbox One S controller fully functional over Bluetooth? I can't get my Select button to be recognized in Input Configuration. Every other button is fine. What's more, if I press the Select button to initiate the configuration, it shows "Keyboard" rather than "Xbox Wireless Controller" on-screen.

I know the physical button is okay because I have two controllers and both are fine wired and both exhibit the same Select button problem over Bluetooth. I have also done a fresh Retropie install.

I am new to the platform and have run out of ideas of things to try. Any leads or ideas most welcome.

Should I submit this as an issue here?

[Spiffyk]

After doing pretty much what @terramare did (upgrading the firmware via a VM and disabling ertm) I also managed to connect my Xbox One S controller via bluetooth. However, the mappings are all messed up with many games. I have found one oddity that might be related to the problem: When using jstest-gtk, the controller is displayed as Microsoft X-Box One S pad when hooked up using a cable. However, when I connect it via bluetooth, it is displayed as Xbox Wireless Controller. Also, all the mappings of buttons and axes are in a different order and have different names for each of these cases. There are also more buttons registered when it's connected via Bluetooth.

Here's what it looks like when connected via USB:

Here's what it looks like when connected via Bluetooth:

[cgutman]

Yes, that's because the controller exposes an Android-friendly mapping over Bluetooth since the November firmware update.

This is also the reason that some special buttons like back don't work correctly in some applications. They are now HID Consumer usages rather than HID Button usages. This is required to get the desired back and home behavior on Android's default keymap.

I believe an SDL2 patch has been checked in to fix the inability to use consumer buttons in controller configurations.

[DigitalKrony]

@terramare - I wasn't able to try things out til now. I've been denied permission by the system to run the bash task successfully. Trying to track down the case of that now. So as of right now, I've had not progress.

[terramare]

@DigitalKrony Do you mean when you are trying to run the echo command? Depending on your distro, first type sudo su, followed by the echo command, and then issue exit to get out of the root account.

[DigitalKrony]

@terramare - Thanks for that. I got it connect. Solid light on the Controller but no access in RetroPie. When I run jstest-gtk the Controller throws numbers so I know it's connected and is sharing data. However, on restart of the PI, I loosed the capability to connect to the controller. Also, because it's not showing up in RetroPie, it's not building a *.cfg file so I can't set the appropriate button mappings.

[DigitalKrony]

Ok, general update.

I did fresh RetroPie install. switched into root and ran the bash command from putty. paired/trusted/connect the XBox One controller. restarted just emulation station (not the entire OS). emulation station was able to read and setup the XBox One Controller. After reboot, however, the XBox controller no longer connects.

Anyone have any ideas?

P.S. when I run the echo bash command from root it doesn't echo anything back. Is that normal? or should I expect a response from a lasting and successful command request?

[terramare]

@DigitalKrony Your echo command is working as it should; this change does not persist a reboot on Retropie. You can add this command to your rc.local file and it will run each time your Pi reboots.

Open the file in a text editor:

sudo nano /etc/rc.local

and then add:

echo 1 > /sys/module/bluetooth/parameters/disable_ertm

near the bottom of the file, but before the exit 0 line at the end.

This should get you to the same boat I'm in, which is a non-functional Select button, but otherwise working bluetooth controller. Please confirm if this is the case.

Would love to know of a workaround.

[DigitalKrony]

@terramare - Got it. I was able to get things up and running. As for the select button issue you're running into. It's a quick and easy solution.

Utilizing $ jstest /dev/input/js0 I was able to record all of the Axes and Buttons associated with the new controller. This is what I got.

select working in game and EmulationStation. EDIT

input_device = "Xbox Wireless Controller"
input_driver = "udev"

input_up_btn = "h0up"
input_right_btn = "h0right"
input_down_btn = "h0down"
input_left_btn = "h0left"

input_a_btn = "0"
input_b_btn = "1"
input_x_btn = "2"
input_y_btn = "3"

input_l_btn = "4"
input_l3_btn = "8"
input_l2_axis = "+2"

input_r_btn = "5"
input_r3_btn = "9"
input_r2_axis = "-3"

input_l_y_plus_axis = "+1"
input_l_x_plus_axis = "+0"
input_l_y_minus_axis = "-1"
input_l_x_minus_axis = "-0"

input_r_y_plus_axis = "+4"
input_r_x_plus_axis = "+3"
input_r_y_minus_axis = "-4"
input_r_x_minus_axis = "-3"

input_start_btn = "7"
input_select_btn = "6"

input_enable_hotkey_btn = "6"

input_reset_btn = "1"
input_exit_emulator_btn = "7"

input_save_state_btn = "4"
input_load_state_btn = "5"
input_state_slot_increase_btn = "h0right"
input_state_slot_decrease_btn = "h0left"

input_menu_toggle_btn = "2"

EDIT These settings were for an RPi2 with a Bluetooth dongle attached. When swapping over to an RPi3, these button settings were no longer valid and the select button no longer throws response in EmulationStation or in JSTest.

[Jacob-Newton]

I've managed to connect mine up to the point where everything works except the select button, and binding the triggers never seems to work correctly in emulation station. Has anyone managed to get these working? Using the model 1708, and a raspberry pi 3 with the built in Bluetooth chip

Also the only way I can get the controller to pair is by using the echo command mentioned above, followed by going into bluetoothctl and running the agent on commands, as well as removing and repairing the controller. Is there any way to run these commands on boot?

[codeart1st]

Hey guys which version of bluez do you use. I have no success with my 5.37 version.

bluetoothctl
scan on
scan off

connect, pair, trust all combinations of it didn't seem to work. Also using register-profile with the given HID uuid didn't work for me.

I also tried with updating the firmware of the gamepad to the newest version, but still not working.

I using an ODROID C2 instead of pi2 or pi3.

[mauriliodc]

@DigitalKrony how did you manage to get the select working via Bluetooth? All my buttons are working but the select (using the built-in Bluetooth of my laptop, 16.04 4.4.0-31)

[DigitalKrony]

@mauriliodc I gotta be honest, I didn't do anything special. I was using a Raspberry Pi 2 and a Bluetooth Dongle. But when I moved the SD card with the active OS loaded on it to a Pi 3 and a built-in BT, I got totally different button mappings and the select button no longer worked.

[howl]

The issue with the keys is more than only the back, homepage, gas, brake codenames issue.

When using with usb cable the module used is xpad, and it works as expected, I mean, the buttons and axes the pad have are detected. When using with bluetooth connection xpad is not used, I suppouse that there is a generic bluetooth hid, and the problem is that despite select becames back and mode becames homepage, there are buttons detected that doesn't exists in the pad.

This makes A button0, B button 1, X button 3 and Y button 4, and the button 2 doesn't exists in the pad.

With evtest and usb you can see:

Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x45e product 0x2ea version 0x301
Input device name: "Microsoft X-Box One S pad"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 304 (BTN_SOUTH)
    Event code 305 (BTN_EAST)
    Event code 307 (BTN_NORTH)
    Event code 308 (BTN_WEST)
    Event code 310 (BTN_TL)
    Event code 311 (BTN_TR)
    Event code 314 (BTN_SELECT)
    Event code 315 (BTN_START)
    Event code 316 (BTN_MODE)
    Event code 317 (BTN_THUMBL)
    Event code 318 (BTN_THUMBR)
  Event type 3 (EV_ABS)
    Event code 0 (ABS_X)
      Value   1538
      Min   -32768
      Max    32767
      Fuzz      16
      Flat     128
    Event code 1 (ABS_Y)
      Value    582
      Min   -32768
      Max    32767
      Fuzz      16
      Flat     128
    Event code 2 (ABS_Z)
      Value      0
      Min        0
      Max     1023
    Event code 3 (ABS_RX)
      Value   -439
      Min   -32768
      Max    32767
      Fuzz      16
      Flat     128
    Event code 4 (ABS_RY)
      Value   -340
      Min   -32768
      Max    32767
      Fuzz      16
      Flat     128
    Event code 5 (ABS_RZ)
      Value      0
      Min        0
      Max     1023
    Event code 16 (ABS_HAT0X)
      Value      0
      Min       -1
      Max        1
    Event code 17 (ABS_HAT0Y)
      Value      0
      Min       -1
      Max        1
  Event type 21 (EV_FF)
    Event code 80 (FF_RUMBLE)
    Event code 81 (FF_PERIODIC)
    Event code 88 (FF_SQUARE)
    Event code 89 (FF_TRIANGLE)
    Event code 90 (FF_SINE)
    Event code 96 (FF_GAIN)
Properties:

And with bluetooth:

Input driver version is 1.0.1
Input device ID: bus 0x5 vendor 0x45e product 0x2fd version 0x903
Input device name: "Xbox Wireless Controller"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 158 (KEY_BACK)
    Event code 172 (KEY_HOMEPAGE)
    Event code 304 (BTN_SOUTH)
    Event code 305 (BTN_EAST)
    Event code 306 (BTN_C)
    Event code 307 (BTN_NORTH)
    Event code 308 (BTN_WEST)
    Event code 309 (BTN_Z)
    Event code 310 (BTN_TL)
    Event code 311 (BTN_TR)
    Event code 312 (BTN_TL2)
    Event code 313 (BTN_TR2)
    Event code 314 (BTN_SELECT)
    Event code 315 (BTN_START)
    Event code 316 (BTN_MODE)
    Event code 317 (BTN_THUMBL)
    Event code 318 (BTN_THUMBR)
  Event type 3 (EV_ABS)
    Event code 0 (ABS_X)
      Value  34120
      Min        0
      Max    65535
      Fuzz     255
      Flat    4095
    Event code 1 (ABS_Y)
      Value  33514
      Min        0
      Max    65535
      Fuzz     255
      Flat    4095
    Event code 2 (ABS_Z)
      Value  32261
      Min        0
      Max    65535
      Fuzz     255
      Flat    4095
    Event code 5 (ABS_RZ)
      Value  32244
      Min        0
      Max    65535
      Fuzz     255
      Flat    4095
    Event code 9 (ABS_GAS)
      Value      0
      Min        0
      Max     1023
      Fuzz       3
      Flat      63
    Event code 10 (ABS_BRAKE)
      Value      0
      Min        0
      Max     1023
      Fuzz       3
      Flat      63
    Event code 16 (ABS_HAT0X)
      Value      0
      Min       -1
      Max        1
    Event code 17 (ABS_HAT0Y)
      Value      0
      Min       -1
      Max        1
  Event type 4 (EV_MSC)
    Event code 4 (MSC_SCAN)
Properties:

So over bluetooth there are 17 buttons where the pad only have 11, BTN_C, BTN_Z, BTN_TL2, BTN_TR2, BTN_SELECT and BTN_MODE shouldn't appear.

Also over usb with xpad there are events for force feedback to work, but they aren't over bluetooth.

And over bluetooth event msc scan appears.

I don't know where to file bug for the bluetooth mapping get corrected.

Also using MAME under windows it shows button names, for example, Joy 1 button 0 is shown in linux but in Windows shows something like this Joy 1 Button A.

[daviderickson]

All- I've got a couple of fixes that solve the select problem for Retropie emulators using libsdl or libretro:

https://github.com/libretro/RetroArch/pull/4692 - MERGED

https://github.com/RetroPie/SDL-mirror/pull/4 https://github.com/RetroPie/SDL-mirror/pull/5 https://github.com/RetroPie/SDL-mirror/pull/6

The last three have not been merged, despite the fact that the code in the pull requests is actually just backported code that has already been accepted into libsdl upstream. I encourage you to comment on these and encourage @joolswills to test/merge them.

[howl]

The problem about appearing more buttons than the pad have over bluetooth is not related to that patches.

[daviderickson]

@howl the problem at least in Retropie is that the emulators and their libraries are not expecting to scan for key codes outside of a very specific range, and the Xbox One pad via Bluetooth is sending these keys. So these patches fix that. The main problem folks were reporting there was the lack of a select button, which is one of these other key codes.

[howl]

I know that issue, moreover there should be also lack of MODE button as it's HOMEPAGE button over bluetooth, also I don't know in retropie, but it's very possible to be also a problem with the button order, as there are buttons detected over bluetooth than doesn't exists in the pad.

Also if we are 100% purist, all this issue is not related to xpad, and that's what i'm asking for, where is the code for the mapping of the pad over bluetooth? In BlueZ layer? or evdev input layer? Because there are more issues over bluetooth to address, I repeat not related to xpad, like your patches that also are not related to xpad.

[howl]

I have found that in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/input/gamepad.rst says the mapping scheme for gamepads over the kernel.

There are discrepancies with the xbox one buttons over usb and over bluetooth as north and west buttons are swapped, Y should be north button but it's west, and X should be west but it's north. Also with xbox 360 pads north and west are also swapped.

Also If I understand it right DPAD should be buttons instead axis, as hat axis are for pressure buttons and at least the xbox pads I could test are just 0 1 buttons.

[BlackVodka]

Hi there folks, please excuse my short question here in between your discussion: @daviderickson, I cloned and compiled your forked and patched SDL repo from https://github.com/RetroPie/SDL-mirror.git and built and installed that on my retropie / RPi 3 system, as well. Also, I built the current master of Retroarch, as your patches are already merged into upstream/master branch there AFAIK. Shouldn't the select button on my Xbox One Bluetooth pad now be working? It still outputs justs an '@' in jstest . Am I missing something here, perhaps something quite stupid as a 'sudo ldconfig' or so? I'd really love to get this pad working here. Thanks in advance and let me know if I could anyhow help you or if you need more information.

[Spiffyk]

@BlackVodka I've been facing this problem yesterday. I've found that the Xbox One S controller probably has two modes for Bluetooth. One intended for Android (which causes these problems) and one intended for Windows (which works correctly). My assumption is that these modes are set via some signal from the host (that xpad does not send). I managed to switch the controller into "Windows mode" by connecting it to a Windows machine via Bluetooth.

edit: fix typo

[BlackVodka]

@Spiffyk Thanks for your quick response. This is an interesting idea, will try that. Have you complete unpaired the controller from the Pi before connecting to the windows client? Also, has anybody tried the original 'Microsoft Wireless receiver' bluetooth-dongle on the pi? Perhaps this thingy does some sort of remapping? edit ok, nothing changes when using the microsoft bt receiver, blacklisted btbcm and re-paired the pi, no change visible in jstest at all.

[Spiffyk]

@BlackVodka Well I haven't tried it with a Pi, I use Ubuntu on my laptop but I don't think this behaviour would be affected by this. I also assume the vendor of your Bluetooth receiver has nothing to do with this, I'd say this is a software issue (may or may not have to do with xpad directly, I don't know what xpad does and does not deal with exactly).

Regarding your question: I think I did unpair the controller from my laptop before trying to connect it to a Windows PC. Basically what I did was unpair the controller from my laptop, paired it with the Windows machine, waited for Windows to identify the device as an Xbox Controller, then unpaired it from the Windows machine and paired it back to the laptop and since then it worked as intended.

[daviderickson]

@BlackVodka FYI the receiver is actually 802.11 not bluetooth.

[howl]

@Spiffyk I will try too, I suppouse that the "Windows mode" that Windows sets, last till the controller is blinking without auto powering off. I will try to check also to pair with an android phone when in that mode.

Anyways at least me the controller in bluetooth mode doesn't use xpad at all, it gets connected as a standard bluetooth hid device.

PD: Which Windows version are you using?

[Spiffyk]

@howl I have no idea when the mode is set on the controller as I had it running fine in the "Windows mode" and then for some reason it switched to the "Android mode"... but now that I'm thinking about it, that might be the case. Let me try, too.

I used Windows 10 for this, as it has the Xbox Accessories app that can be used for updating the controller's firmware.

[BlackVodka]

@Spiffyk I fiddled here a bit around between my raspberry and my windows 10 pc and, unfortunately, wasn't successful in getting any change in the pad's behaviour. I tried just going from one room into the other and connect it to the windows pc, tried to first unpair it from the pi and just afterwards pairing it with the PC, followed by a reconnect/repair with the pi and all such scenarios...no luck :/ You were absolutely right btw. that using the original/bundled bt-receiver by microsoft (and disabling the pi's internal bluetooth by blacklisting the according module) didn't change anything at all.

@daviderickson I thought these new One Pads are using bluetooth (I'm connecting it using the RPi3's internal bluetooth, not the wireless chipset AFAIK) ? What I was talking about are the receivers coming along with these new pads (I bought a bundle about a month ago) and these are clearly stated as bluetooth device in windows.

@howl Okay, interesting. Just for learning how things work, how did you notice that? Does anyone know how e.g. a ps3 controller (which works here like a charm btw.) does work (precisely, the handling of the bt-stack and the kernel driver module itself)? This has to be kind of the same way, like kernel -> bt-stack -> gamepad kernel module/driver , so I'm curious what's getting handled differently with an ps3 pad in comparison to the one pad?

[Spiffyk]

I'm confused. Once I got it into the "Windows mode", I can't seem to get it back to the "Android mode". So I can't test this. Of course no modes are mentioned anywhere officially but I'm pretty sure they are a thing because of the inconsistent behaviour. I'll try investigating further.

@BlackVodka The new XBOne pads use 802.11 when connected via the dongle or directly to the console. They only use Bluetooth with a PC or another Bluetooth-capable device.

[howl]

@Spiffyk I can't get the windows mode, perhaps I don't do like you do.

I pair it in Windows 10 with it's bluetooth screen, then I switch back to linux and I press again the connect button in the pad to pair it with linux (it doesn't pair if I don't do it). When testing I get the usual homepage, back, brake, gas button trigger names.

[howl]

@BlackVodka I don't have xpad module loaded if I only connect it with bluetooth, that how I notice it and also by dmesg, as it shown hid-generic. When using the pad connected to with the usb cable then xpad gets loaded and works with it, and it's ok with no issues, the issues are only when using over bluetooth (buttons and triggers that doesn't exits detected and buttons working as gas, brake, homepage, back instead of z, rz mode and select).

[Spiffyk]

I've been fiddling around with it and I found out I don't have the xpad module loaded either when connected via bluetooth, even though my controller is working properly... so it may not even be an xpad issue after all and the problem might be lying elsewhere. But I'm really running out of ideas...

[howl]

@Spiffyk it's strange as if you connect the usb the pad stops bluetooth comunication.

The cable you are using is a data cable or it only have ground and 5 V pins used.

I'm going to try blacklisting the xpad module to test if it retains bluetooth connection even with the usb cable.

[howl]

@Spiffyk I have done the test and only if I don't let xpad module to be loaded it stays connected over bluetooth even with the usb cable. But if xpad it's present when you connect it via usb cable it gets loaded, and the the bluetooth connection it's closed.

Test the pad with xpad loaded and connecting it via usb cable, you will see that then the pad behaves like the previous pads, z and rz triggers, correct number of buttons detected... and xpad manages it.

[BlackVodka]

Hi, just here from work in my lunch break: I compared (just a quick view) how the ps3 controller works (https://github.com/RetroPie/sixad/blob/master/sixad-bin.cpp) compared to https://github.com/paroj/xpad/blob/master/xpad.c . Is it possible that's xpad just doesn't know anything of bluetooth and due to that the linux kernel manages this HID device, because I cannot find anything regarding to accessing the device besides directly via bluetooth in xpad's source? (in comparison sixad has a bluetooth HID daemon hid_server() in bluetooth.cpp).

[howl]

Could be, but if the bugs can be addressed in the generic hid of the kernel that could be interesting, as the pad could work out of the box in more systems. For example in fedora to get xpad you must install kernel-modules-extra or from another external repository.

I don't know where can be found the code that actually manages the pad over bluetooth.

[cgutman]

Ok there's a ton of confusion here.

Xpad has nothing to do with dealing with the Xbox One S Controller when connected via Bluetooth. The device exposes a standard HID interface over Bluetooth that requires no special driver like xpad to handle.

I do not know of any bugs affecting the HID stack that affects this gamepad when connected via BT. However, there is an issue with the standard Linux Bluetooth stack which prevents the gamepad from connecting by default.

Valve has written a hack to workaround the issue (which also changes mappings, but this is not necessary with a patched SDL): https://github.com/ValveSoftware/steamos_kernel/commit/549c3dc10fa3749b3999549a2672b14bf0e9786d

Android's Bluetooth stack is not affected by this behavior.

[howl]

@cgutman with generic hid over bluetooth more than the mappings, there is the problem that there are more buttons and axes that the pad have. For example in mame you have to rebind all the controls as the button2 in the pad doesn't exists.

[cgutman]

While not ideal, HID devices exposing extra non-functional buttons is not uncommon and should be properly handled by userspace. What exactly is problematic about having the extra buttons?

[howl]

For example mame doesn't work out of the box (I don't mean the android mappings about back and homepage, I'm waiting for the sdl update but because the games I use doesn't use so many buttons I have workaround it with the top buttons).

The issue here is when in bluetooth the first buttons the pad reports are: Event code 304 (BTN_SOUTH) Event code 305 (BTN_EAST) Event code 306 (BTN_C) Event code 307 (BTN_NORTH) Event code 308 (BTN_WEST)

So mame takes button 0 the south one that it's A button, button 1 east that is B button, and then button 2 is btn_c that doesn't exists in the pad, so the mame automapping fails and you have to reset the buttons. Doesn't happen only with that button because there is also the btn_z and the triggers z and rz despite they don't work as gas and brake take into account. The problem here is that the extra buttons detected makes automapping systems to fail by assigning the inexistant buttons.

One of the most typical system for example neogeo. If you start mame and play metal slug that uses just the first 3 buttons, you can't throw grenades as the button doesn't exists.

For my use case I have made my own mame ctrlr.ini file to workarround it without having to remap manually all the machines, but it could be interesting that it works out of the box, also because the same mapping would work for all the pads.

[cgutman]

Yes, this is simply a bug in MAME. It should not assume the first 4 buttons are ABXY - there's no requirement for that to be true. They should add special handling in their automapper for this device.

[Spiffyk]

So basically, as far as xpad is concerned, this issue is invalid, right? Shouldn't it be marked as such to prevent further confusion?

[howl]

@Spiffyk indeed.

@cgutman thanks for the explanation, I will try to file a bug to mame, at least in Windows mame shows even the button names in the pad instead of button# so I think the linux event device or it's detection should be improved, don't know if in mame, sdl or in linux generic hid.

[lowlyocean]

Alright - with Ubuntu 16.04 I've downloaded kernel sources and rebuilt hid and xpad modules after manually adding the changes to hid-core.c, hid-microsoft.c, hid-ids.h, and xpad.c from commit d6afa93787217033a0f0f5db5f557b252c36260e of ValveSoftware/ steamlink-sdk (recommended by user @mooware here.) Instructions for building kernel modules can be found here. jstest-gtk now recognizes the controller, as long as you add the following line to /etc/modprobe.d/disable_bluetooth_ertm.conf, reboot, and re-pair the controller:

options bluetooth disable_ertm=1

@cgutman, has there been any update to make mapping over Bluetooth non-Android-friendly (i.e., just like it is over USB)? I want to use the controller for Steam games, not for RetroPie.

[cgutman]

The HID mapping will never be the same as the xpad mapping.

xpad was written years before this gamepad was released and many userspace programs depend on its mappings the way they are today. Since we don't have a time machine, we can't go back and make xpad match Microsoft's HID mappings. Similarly, there are userspace programs that depend on the HID mappings present over Bluetooth as they exist today (Chrome, for example).

Changing xpad's mappings to match HID or HID's mappings to match xpad would break userspace, so it would not be accepted upstream. The onus is on userspace (generally libraries like SDL) to abstract gamepad device differences and quirks.

[lowlyocean]

Sounds like middleware that can present the Bluetooth HID as an xpad device is out of the question. So in practical terms, unless Steam games running on Linux are coded to support the Bluetooth HID mapping directly or via libraries like SDL we should stick to USB rather than bluetooth.