Hi Roderick, Welcome back, and thanks for replying! Comments below :) On 8/9/24 08:11, Roderick Colenbrander wrote:
Preferably it would be some type of quirk.
Agreed.
Just changing the patterns is not a good idea also in case hypothetically other features were get added (volume control for the speaker, microphone settings,..) and other features which work through the same output report and various of these devices probably won't handle (or it is hard to predict).
I think at this point the discussion and/or your concerns may have diverged because of misunderstandings. I do not intend to touch any upper bits in valid_flag0.
I've been thinking about this, and my conclusion is that both my patch (v1) and its description were trying too hard to squeeze in as much context as possible. I think they were too hard to understand - sorry!
So to make things easier to understand for everyone, I have sent a v2 of the patch. It's really short now, and it should be obvious that I am not touching any flag bits that the driver didn't touch already.
Hopefully this can get everyone on the same page - could you please have a look? Maybe this patch is actually fine with you.
I have been trying to think of ways to realize a quirk. I think we need to search it in the HID reports. Either do some tests on reports we know aren't supported (ugly). It can also be that the calibration data is invalid (zeros, which we now initialize to a default). Or perhaps is the firmware/hardware version related HID report returning anything interesting?
I'll need to have a look, but there's a catch here: Bluetooth devices can't be tested for some of the quirks that USB devices have, for example the MAC address report that clones usually don't implement. I wish to fix both classes of devices, since I've seen a quirky BT device some (longer) time ago.
Could you please look at the new PATCHv2 first? Maybe that one is fine with you, and it all boils down to me just not presenting things well in v1.
Thanks :) Max
