On Monday 15 April 2024 20:31:14 CEST Hans de Goede wrote: > Hi, > > On 4/15/24 5:54 PM, Benjamin Tissoires wrote: > > [Ccing Hans as well for input] > > > > On Apr 13 2024, kde@xxxxxxxxxxxx wrote: > >> From: Allan Sandfeld Jensen <allan.jensen@xxxxx> > > > > FWIW, this patch neesd a commit description and signed-offs > > Will add. > > FWIW I'm also not in favor of stretching drivers/hid/hid-logitech-dj.c > even further to also support the new bolt stuff. > > AFAIK the new bolt stuff is significantly different. > > Allan, I see in your other reply that you are mainly after > highres scrolling and since the bolt receiver does not do > per paired device addressing I wonder if you cannot just > get that by treating the bolt receiver as a wired HIDPP > device and just directly listing it as such in > hid-logitech-hidpp.c ? > > The whole purpose of hid-logitech-dj.c is to create 1 virtual > hidpp devices per paired device and with bolt that is not > possible, so I think that we should circumvent hid-logitech-dj.c > for bolt and if we want to use any hidpp features do so > by directly listing the receivers in hid-logitech-hidpp.c . > I think the bolt receiver is able to separate devices, but yes, it appears the way it transmits device IDs and pairs has changed (some new registers it looks like). I am removing this part of the patch. I am not adding the Bolt receiver to hid-logitech-hidpp.c either though, because it doesnt work for me, and I havent invested time yet to figure out what would be needed to get it to work. I will transmit a patch with just the new bluetooth ID, and add a few more I managed to find to fill out hid-logitech-hidpp.c Best regards Allan Sandfeld Jensen