Skip to content
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

Closed
Komoszek opened this issue Mar 9, 2021 · 28 comments
Closed

Comments

@Komoszek
Copy link

Komoszek commented Mar 9, 2021

Your system information

  • Steam client version: 1614994836
  • Distribution: Manjaro 20.2.1
  • Opted into Steam client beta?: Yes
  • Have you checked for system updates?: Yes

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

Local Device Found
  type: 28de 1106
  path: /dev/hidraw0
  serial_number: cf:14:07:ae:84:e5 - 0
  Manufacturer: 
  Product:      SteamController
  Release:      0
  Interface:    -1

Controller uses V2 HID protocol
!! Steam controller device opened for index 0.
Steam Controller reserving XInput slot 0
Controller 0 connected, configuring it now...
Installing breakpad exception handler for appid(steam)/version(1614994836)
Disconnecting zombie controller 0
Scheduled disconnect of controller 0
Installing breakpad exception handler for appid(steam)/version(1614994836)
Installing breakpad exception handler for appid(steam)/version(1614994836)
Warning, couldn't get controller details for SC, PID=4358
CGetControllerInfoWorkItem::RunFunc: Read failure.
Installing breakpad exception handler for appid(steam)/version(1614994836)
Warning, couldn't get controller details for SC, PID=4358
CGetControllerInfoWorkItem::RunFunc: Read failure.
Warning, couldn't get controller details for SC, PID=4358
CGetControllerInfoWorkItem::RunFunc: Read failure.
Warning, couldn't get controller details for SC, PID=4358
CGetControllerInfoWorkItem::RunFunc: Read failure.
Warning, couldn't get controller details for SC, PID=4358
CGetControllerInfoWorkItem::RunFunc: Read failure.

Steps for reproducing this issue:

  1. Install bluez/bluez@35a2c50 or newer
  2. Connect controller via Bluetooth
  3. Open Steam
@kisak-valve
Copy link
Member

Hello @Komoszek, a regression in bluez should also be mentioned to the bluez devs if it hasn't been already.

@taylor85345
Copy link

Can confirm the same behavior on two separate Manjaro systems.

@padovan
Copy link

padovan commented Mar 11, 2021

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.

@taylor85345
Copy link

Passed this on to Ricardo at the provided link and got this response:

Thank you. Yes, I'm aware of that. The bug I was inspecting is sorted out now, but yes, we had to take into account the change in how BlueZ provides the report IDs starting in 5.56.

I guess that's something that everyone using hidraw devices with multiple report IDs will have to take care of when they switch to BlueZ 5.56 or later.

https://lore.kernel.org/linux-bluetooth/9fed57047ba6145af64ac00579f8ffb7cd03a55d.camel@collabora.com/

@clst
Copy link

clst commented May 7, 2021

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?

@senpl
Copy link

senpl commented May 8, 2021

Is there some kind of workaround other than downgrading bluez?

yes. Use of cable, but this is also not very reliable.

@clst
Copy link

clst commented May 8, 2021

Yes, thanks. I can confirm spanning 5m of USB cable across my living room works. It's less than ideal though.

@tylergale
Copy link

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?

@stheid
Copy link

stheid commented Jun 27, 2021

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.

@themchn
Copy link

themchn commented Jul 28, 2021

I am also experiencing the exact same issue.

@wiccan2
Copy link

wiccan2 commented Jul 31, 2021

Getting the same on Arch Linux with latest Bluez, had to downgrade to get the controller to work again which isn't ideal.

@Komoszek
Copy link
Author

Komoszek commented Aug 1, 2021

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.

@stheid
Copy link

stheid commented Aug 1, 2021

Good debugging, hopefully someone will take care of that soon.

@Komoszek
Copy link
Author

Komoszek commented Sep 4, 2021

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.

@stacyharper
Copy link

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…

@stheid
Copy link

stheid commented Sep 6, 2021

I think they will fix it eventually as SteamDeck is also Arch based. But the intermediate fix is sooo appreciated!

Plagman referenced this issue in bluez/bluez Sep 7, 2021
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.
@Plagman
Copy link
Member

Plagman commented Sep 7, 2021

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.

@Plagman
Copy link
Member

Plagman commented Sep 7, 2021

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.

@kakra
Copy link

kakra commented Sep 7, 2021

@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.

@abcminiuser
Copy link

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.

@ccgauvin94
Copy link

Issue is present for me on openSUSE Tumbleweed with BlueZ 5.61

@padovan
Copy link

padovan commented Sep 9, 2021 via email

@Komoszek
Copy link
Author

Komoszek commented Oct 9, 2021

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.

@ccgauvin94
Copy link

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.

@taylor85345
Copy link

Also confirming this fixed in Manjaro

@BarrelKnight723
Copy link

I have this issue on Elementary OS 6 Odin but I don't have BlueZ installed

@IGLOU-EU
Copy link

Fixed in Archlinux with BlueZ 5.62-1

@kisak-valve
Copy link
Member

Closing per the last several comments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests