Steam Controller not detected over bluetooth

[nickjwhite]

I've been using sc-controller for a few years with the official sc dongle, and it's worked like a charm. I recently switched to Bluetooth mode for the first time, and sc-controller no longer picks up the controller at all. Steam detects it fine, though, so I know the bluetooth connection is made successfully.

I'm using the 0.4.8 AppImage on Debian Buster, with the udev rules installed. The controller is in the basic mouse/kb mode when connected to bluetooth, but no registered controller shows up on sc-controller. Nothing except for the generic initialization messages show up when I run daemon debug.

I'm a bit stuck as to how to debug this further. Any suggestions?

[stacyharper]

I lost my dongle so I must use bluetooth mode. It looks like sc-controller doesnt detect my controller or it just does not trigger any input. My SC mouse seems to works in sway (moving and right/left clicking). I dunno how both could conflict

[nickjwhite]

I lost my dongle so I must use bluetooth mode. It looks like sc-controller doesnt detect my controller or it just does not trigger any input. My SC mouse seems to works in sway (moving and right/left clicking).

Same here. The basic mouse functionality is the steam controller in so-called "Lizard Mode", which is the default before something like Steam or sc-controller picks it up, as it just presents itself as a mouse & keyboard to the operating system.

Hopefully someone more knowledgeable can weigh in on what might be the cause of sc-controller failing to recognise it in bluetooth mode for us.

In the meantime I have just been using the controller wired, which does work fine for me.

[LuisCondeVela]

Have the same issue, only works on wired or with the dongle, SC Controller does not recognize the controller at all on Bluetooth mode.

[Ryochan7]

I solved this problem recently in the Python 3 fork. The key problem was updates to BlueZ changing how sending feature reports work; the latest BlueZ version that I had tested that worked with the old code was 5.61 IIRC. The only change needed was to set a feature report ID of 3 for the first byte. A one line change.

https://github.com/Ryochan7/sc-controller/commit/321e6de4aa1994228082a30dbc9161e36a3d38f2

[nickjwhite]

Thanks @Ryochan7, excellent detective work! I just created a pull request with that fix, #669 so hopefully it can be incorporated into the next release.

[kozec]

I've merged PR, but I'll have to get new enought bluez and test whether this change doesn't break compatibility with older. Any idea which specific version caused the issue?

[nickjwhite]

I've merged PR, but I'll have to get new enought bluez and test whether this change doesn't break compatibility with older. Any idea which specific version caused the issue?

Thanks @kozec, I'm not exactly sure, but FWIW I'm on 5.64, where it definitely fails without the fix, and @Ryochan7 said above that 5.61 was the latest version he tested where the old code worked, so that implies it was either 5.62, 5.63 or 5.64 that introduced the issue.

[Ryochan7]

Not sure what change happened in between BlueZ 5.61 and 5.64 that caused this particular breakage. Ended up just testing some variables in some example hidraw test C code and finally got a feature report through successfully.

There were behavior changes in BlueZ that even broke Steam Controller BLE support in Steam for a while with version 5.56. Maybe the stack now more actively checks for known feature reports listed in the HID report descriptor.

https://github.com/ValveSoftware/steam-for-linux/issues/7697

Without adding report ID 3 as the first byte of the feature report, BlueZ 5.64 will cause the sendFeatureReport call to error out with an Input/output error. BlueZ 5.61 and 5.60 were tested with the feature report change and the change worked fine in those versions as well. Also, although some people might not like it, solving this problem was the key that allowed feature reports to successfully get sent to a BT connected Steam Controller on my Windows test mapper. Many of the recent BLE changes were first tested on Windows.

[Ryochan7]

Although the change has already been committed to this repo, I will confirm that the source code for VSCView ExtendInput also uses feature report ID 3 for its BLE reader. That was the only other Windows app (besides Steam Input) I found that could read from a BT connected Steam Controller. It seems like the old behavior in SC Controller was wrong but luckily it worked for as long as it did.

https://github.com/Nielk1/VSCView https://github.com/Nielk1/ExtendInput/blob/e3895fa2cc5340c19c35f4eceead7ce5219971c4/ExtendInput/ExtendInput/Controller/SteamController.cs#L647

[pattontim]

I am observing similar behaviour when using the SD prerelease and a steam controller over Bluetooth. Maybe related to the version shipping with OS Holo?

[pattontim]

On the SD, BT mode exhibits this exact same behaviour when both Steam is closed or running and also when I undid the BT change. This leads me to believe its unrelated to the fix above.

[nickjwhite]

@pattontim I'm not sure I understand what behavior you're seeing on the Steam Deck (presuming that's what "SD" means here). FWIW, I have successfully connected my Steam Controller to a Steam Deck using Steam on multiple occasions (as expected), but haven't tried sc-controller on a Steam Deck.

[pattontim]

Steam OS Holo returns caps for the BT address, here's my hotfix. End of day now so will try to push tomorrow, device_monitor.py:

if node_addr == addr:
     return node

            try:
                # SteamOS 3 "Holo" return caps
                if node_addr.lower() == addr.lower():
                    return node
            # is none
            except AttributeError:
                pass

This makes BT devices work on Holo