-
Notifications
You must be signed in to change notification settings - Fork 175
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Steam fails to configure Steam Controller via bluetooth with bluez 5.56 #7697
Comments
Hello @Komoszek, a regression in bluez should also be mentioned to the bluez devs if it hasn't been already. |
Can confirm the same behavior on two separate Manjaro systems. |
A similar issue was reported in the BlueZ community: https://lore.kernel.org/linux-bluetooth/f6764fe94d45ff9211674c5799b193d15385a056.camel@collabora.com/#t - It could be interesting to mention this one there. |
Passed this on to Ricardo at the provided link and got this response:
|
This is still an issue with the latest Steam Client. It sadly makes my couch gaming with the Steam Controller pretty limited. SC-Controller works fine but I can only play games that don't use the Steam Client with it. Is there some kind of workaround other than downgrading bluez? |
yes. Use of cable, but this is also not very reliable. |
Yes, thanks. I can confirm spanning 5m of USB cable across my living room works. It's less than ideal though. |
Can confirm that it effects the new Ubuntu 21.04 on June 27, though I am still unsure based on this thread whether it is a confirmed Bluez or Steam Controller issue? |
Its not confirmed, but given the fact that other software can use the controller just fine with this bluez version i recon its a steam-for-linux issue. |
I am also experiencing the exact same issue. |
Getting the same on Arch Linux with latest Bluez, had to downgrade to get the controller to work again which isn't ideal. |
I've more or less found out why Steam Controller is not working with Steam and works perfectly fine with sc-controller. So the whole issue stems from commit I linked in my first comment. Basically it slightly changed data read from device in some cases. Both steam and sc-conttroller access SC via hidraw api. After getting out of lizard mode (basic keyboard/mouse HID) Steam calls ioctl with HIDIOCGFEATURE(20) on opened SC descriptor (probably to get some data required to identify SC or data showing that SC is out of lizard mode?). Data returned by ioctl on bluez pre-commit (5.55) is actually different from data returned post-commit (5.56 and newer; there are report id byte(s) prepended in newer versions). sc-controller is not affected by this change because it doesn't actually call ioctl with HIDIOCGFEATURE and everything else seems to be the same. |
Good debugging, hopefully someone will take care of that soon. |
As we approach 6 months of this issue, I've finally created a workaround that doesn't require you to downgrade to older versions of bluez. It is by no means perfect, but it should probably work, as long as you have only one SC connected at the same time. You can find it here https://github.com/Komoszek/sc-ble-bridge. |
I want to cry when I see that a random took so much time to make something that clean while Valve cant quickly fix this minor regression… |
I think they will fix it eventually as SteamDeck is also Arch based. But the intermediate fix is sooo appreciated! |
If the HID subsystem requests a HID report to be read from the device, we currently incorrectly strip off the first byte of the response, if the device has report IDs set in the HID report descriptor. This is incorrect; unlike USB HID, the report ID is *not* included in the HOG profile's HID reports, and instead exists out of band in a descriptor on the report's bluetooth characteristic in the device. In this patch, we remove the erroneous stripping of the first byte of the report, and (if report IDs are enabled) prepend the report ID to the front of the result. This makes the HID report returned indentical in format to that of a USB HID report, so that the upper HID drivers can consume HOG device reports in the same way as USB.
I'm not aware of a way we could use to detect pre-5.56 versions of BlueZ vs. post-5.56 in a distro-agnostic way, so I don't know that we could fix this only on our side without also breaking the subset of users that are not yet on 5.56. We are looking into it. |
Looks like we might have a way to work around it in a way that works with both versions, given that in our protocol, the first byte of valid reports is guaranteed to not be 3, which is our report ID. |
@Plagman Couldn't you just look at the report length and compare that to the length reported by the HID descriptor? If the length is x+1, it has the report ID, if it is just x, it doesn't have the ID prepended... You could still add another sanity check if the first byte matches any of the known report IDs. |
Oops, apologies for breaking Steam - but the previous BlueZ behavior was critically broken. You should indeed be able to probe for the correct behavior by checking that the first byte is the report ID you requested, and the length is correct. Broken BlueZ versions strip off the report ID from the returned data, and mangle the last byte of the report. |
Issue is present for me on openSUSE Tumbleweed with BlueZ 5.61 |
We hit what I believe is the same issue on fwupd. Here's how it was solved:
https://github.com/fwupd/fwupd/blob/f6a8c740e0c3fea700cdc51989155e771c174518/plugins/pixart-rf/fu-pxi-ble-device.c#L167
…On Thu, Sep 9, 2021 at 2:50 PM Colin Gauvin ***@***.***> wrote:
Issue is present for me on openSUSE Tumbleweed with BlueZ 5.61
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#7697 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAJ23677USSALP4OR2H6S3UBDXV3ANCNFSM4Y3XIU6Q>
.
|
I've noticed that SC finally works via BLE with newest Steam client, but it wasn't mentioned in any of the Steam Client Beta update announcements. |
Can confirm. I am running openSUSE Tumbleweed 20211005 with Kernel 5.14.6-2 and bluez 5.61-1.5, steam-devices 1.0.0.72-1.9 and Steam package version 1633666232, and the Steam Controller is working fine over Bluetooth on all modes (Desktop, Big Picture, and In-Game). Thank you for fixing this. |
Also confirming this fixed in Manjaro |
I have this issue on Elementary OS 6 Odin but I don't have BlueZ installed |
Fixed in Archlinux with BlueZ 5.62-1 |
Closing per the last several comments. |
Your system information
Please describe your issue in as much detail as possible:
Steam has problem configuring Steam Controller via bluetooth with bluez/bluez@35a2c50 or newer. Controller works just fine in Lizard Mode but refuses to work as soon as Steam tries to configure it. This problem is not present if you connect SC via usb, use older versions of bluez or use any third-party software to configure SC (e.g. https://github.com/kozec/sc-controller).
Related console output
Steps for reproducing this issue:
The text was updated successfully, but these errors were encountered: