Hi Egor, On Tue, Jun 3, 2025 at 10:55 AM Egor Vorontsov <sdoregor@xxxxxxxx> wrote: > > On Tue, 2025-06-03 at 10:40 -0400, Luiz Augusto von Dentz wrote: > > > + /* TODO: we could put the key here but > > > + there is no way to force a re-loading > > > + of link keys to the kernel from here. */ > > > > Not quite following, what key are you talking about? I thought the > > link keys are still generated over Bluetooth, or are you talking about > > passkeys here? > > Hi Luiz, thank you for the quick response! > > If you look a little bit upper, in the `ds4_set_central_bdaddr', you'll > see the exact same comment. As I pointed out, I decided to just > duplicate the code for now, as a proper general implementation might > require some further refactoring of somewhat unrelated code. > > From my understanding of the original author's thoughts combined with > the experimentation I've done, it is about the possibility to directly > provide a generated link key, completely skipping the usual BT bonding > process (that, I positively tested with my script by writing directly > to BlueZ's device `/info' file), instead of writing all zeros and > relying on (I assume?) Just Works repairing on the following connect. Well except if there is some sort of OOB to generate the link key I don't that is possible, note that we don't mark the device as paired so the process of doing CablePairing is just creating a device, then by the time it first connects it will then do the regular pairing. Perhaps it is possible to write the link keys directly via cable but then we need the OOB data, etc, to generate the keys which in my opinion it just extra work that doesn't really add anything if just works, or autopair, is used. > My knowledge in terms of Kernel Bluetooth subsystem doesn't go so far > to actually tackle the problem; it might require implementing a key > reloading ABI in the kernel. On the other hand, there's `btmgmt keys' > command which, I assume, does pretty much that, but I didn't have any > success using it in my testing -- only a full restart of `bluetoothd' > did the thing. > > I'm up to further investigation of this nitpick, as I'd love to see a > seamless pairing process just like it was intended, but I'd need some > assistance in locating the appropriate showstoppers mentioned in that > comment. That said, I don't see this as a stopper for the patch itself. Is it not seamless right now? Doesn't it use 'just works'/autopair? -- Luiz Augusto von Dentz
