Bug caused by moving to BlueZ 5.56 (bytes stripped from HoG reports)

Bug caused by moving to BlueZ 5.56 (bytes stripped from HoG reports)

[Ricardo Cañuelo]

Hi all,

I discovered this fix https://github.com/bluez/bluez/commit/35a2c50 while
debugging a fwupd plugin for a HoG device that implements its FW upgrade
mechanism using vendor-specific HID reports (
https://github.com/fwupd/fwupd/blob/master/plugins/pixart-rf/fu-pxi-device.c).

Initially, the developers were using BlueZ versions prior to 5.56, which is the
first release that includes that fix, so their code was written with that
behavior in mind. After moving to 5.56 we found out it crashed and we needed to
adapt the code to the proper report format. I think this is the kind of issues
that Dean mentioned here 
https://marc.info/?l=linux-bluetooth&m=160590969013204&w=2

Have there been any more reports like this? Is this expected to have a greater
impact than initially thought?

Cheers,
Ricardo

Re: Bug caused by moving to BlueZ 5.56 (bytes stripped from HoG reports)

[Luiz Augusto von Dentz]

Hi Ricardo,

On Thu, Mar 4, 2021 at 9:40 AM Ricardo Cañuelo
<ricardo.canuelo@collabora.com> wrote:
>
> Hi all,
>
> I discovered this fix https://github.com/bluez/bluez/commit/35a2c50 while
> debugging a fwupd plugin for a HoG device that implements its FW upgrade
> mechanism using vendor-specific HID reports (
> https://github.com/fwupd/fwupd/blob/master/plugins/pixart-rf/fu-pxi-device.c).
>
> Initially, the developers were using BlueZ versions prior to 5.56, which is the
> first release that includes that fix, so their code was written with that
> behavior in mind. After moving to 5.56 we found out it crashed and we needed to
> adapt the code to the proper report format. I think this is the kind of issues
> that Dean mentioned here
> https://marc.info/?l=linux-bluetooth&m=160590969013204&w=2
>
> Have there been any more reports like this? Is this expected to have a greater
> impact than initially thought?

Nope, you are the first one to report a problem with this change, so
chances are that what Dean stated probably still holds since the vast
majority of devices didn't care about the report ID. So I suppose the
following code shall take care of it or does it not?

https://github.com/fwupd/fwupd/blob/master/plugins/pixart-rf/fu-pxi-device.c#L170

-- 
Luiz Augusto von Dentz

Re: Bug caused by moving to BlueZ 5.56 (bytes stripped from HoG reports)

[Ricardo Cañuelo]

Hi Luiz

On Thu, 2021-03-04 at 10:44 -0800, Luiz Augusto von Dentz wrote:
> Nope, you are the first one to report a problem with this change, so
> chances are that what Dean stated probably still holds since the vast
> majority of devices didn't care about the report ID. So I suppose the
> following code shall take care of it or does it not?
> 
> 
https://github.com/fwupd/fwupd/blob/master/plugins/pixart-rf/fu-pxi-device.c#L170
> 

Yes, that's how we're dealing with it for now. It's a quick fix, a more general
solution would be to detect the BlueZ version and parse the reports accordingly.
By the way, is there a way to query the version of the running daemon other than
running it with '-v' and parsing the result?

I just wanted to let you know that this can actually happen so you're ready for
it, as there might be more code like this in other projects, although I don't
know how frequent it is for a device to use vendor-specific report IDs.

Cheers,
Ricardo

Re: Bug caused by moving to BlueZ 5.56 (bytes stripped from HoG reports)

[Luiz Augusto von Dentz]

Hi Ricardo,

On Thu, Mar 4, 2021 at 10:57 AM Ricardo Cañuelo
<ricardo.canuelo@collabora.com> wrote:
>
> Hi Luiz
>
> On Thu, 2021-03-04 at 10:44 -0800, Luiz Augusto von Dentz wrote:
> > Nope, you are the first one to report a problem with this change, so
> > chances are that what Dean stated probably still holds since the vast
> > majority of devices didn't care about the report ID. So I suppose the
> > following code shall take care of it or does it not?
> >
> >
> https://github.com/fwupd/fwupd/blob/master/plugins/pixart-rf/fu-pxi-device.c#L170
> >
>
> Yes, that's how we're dealing with it for now. It's a quick fix, a more general
> solution would be to detect the BlueZ version and parse the reports accordingly.
> By the way, is there a way to query the version of the running daemon other than
> running it with '-v' and parsing the result?

Not really, we could possibly add a version over D-Bus but that
wouldn't help for 5.56 anyway.

> I just wanted to let you know that this can actually happen so you're ready for
> it, as there might be more code like this in other projects, although I don't
> know how frequent it is for a device to use vendor-specific report IDs.
>
> Cheers,
> Ricardo
>


-- 
Luiz Augusto von Dentz

Re: Bug caused by moving to BlueZ 5.56 (bytes stripped from HoG reports)

[Taylor Phillips]

Hi Ricardo,

Just passing over this issue in the steam-for-linux github that seems
like it may be related:
https://github.com/ValveSoftware/steam-for-linux/issues/7697.

The latest BlueZ update seems to be causing issues with the Steam
Controller's ability to communicate specifically with the Steam client
over Bluetooth LE. I'm a casual non-dev, so can't tell you much more
than that.

Thanks,

Taylor

On 21/03/04 03:02PM, Ricardo Cañuelo wrote:
> Hi all,
> 
> I discovered this fix https://github.com/bluez/bluez/commit/35a2c50 while
> debugging a fwupd plugin for a HoG device that implements its FW upgrade
> mechanism using vendor-specific HID reports (
> https://github.com/fwupd/fwupd/blob/master/plugins/pixart-rf/fu-pxi-device.c).
> 
> Initially, the developers were using BlueZ versions prior to 5.56, which is the
> first release that includes that fix, so their code was written with that
> behavior in mind. After moving to 5.56 we found out it crashed and we needed to
> adapt the code to the proper report format. I think this is the kind of issues
> that Dean mentioned here 
> https://marc.info/?l=linux-bluetooth&m=160590969013204&w=2
> 
> Have there been any more reports like this? Is this expected to have a greater
> impact than initially thought?
> 
> Cheers,
> Ricardo
> 

Re: Bug caused by moving to BlueZ 5.56 (bytes stripped from HoG reports)

[Ricardo Cañuelo]

Hi Taylor,

On Thu, 2021-03-11 at 08:05 -0700, Taylor Phillips wrote:
> Hi Ricardo,
> 
> Just passing over this issue in the steam-for-linux github that seems
> like it may be related:
> https://github.com/ValveSoftware/steam-for-linux/issues/7697.
> 
> The latest BlueZ update seems to be causing issues with the Steam
> Controller's ability to communicate specifically with the Steam client
> over Bluetooth LE. I'm a casual non-dev, so can't tell you much more
> than that.
> 
> Thanks,
> 
> Taylor

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.

Cheers,
Ricardo