Hi, On Friday, 23 July 2021 09:38:40 CEST Marcel Holtmann wrote: > >>>>> What is the intention to split BR/EDR and LE here. You do know > >>>>> up-front what connection type you are. Trying to figure out from the > >>>>> error code what connection you have been trying to establish is plain > >>>>> wrong.>>>> > >>>> In fact the up-front connection type is not necessarily known. In the > >>>> case of dual-mode devices, such as Bose QC35, a D-Bus client can issue > >>>> Connect(), and it depends on the timing of connection request (adv > >>>> usually arrive first compared to inquiry result), it can be either > >>>> BR/EDR or LE link being established. Another aspect of this is the > >>>> metrics collection, where knowing transport can be handy. For > >>>> instance, we can associate the certain error to particular use cases > >>>> at application layer, and that can help targeting the bottleneck to > >>>> tackle. > >>> > >>> Then we need to find a different way to convey the transport chosen. > >>> Doing this by error message is a bad idea.>>> > >>>>> The description is that you want to know exactly where the connection > >>>>> failed. And I think that can be established independent from the > >>>>> transport.>>>> > >>>> Indeed the intention is to know where it failed exactly. However, as > >>>> mentioned above, transport information is also an important piece of > >>>> information to know. > >>> > >>> We need to find a different way to inform about which transport failed > >>> (or better which was chosen in the first place).> > > I would love to hear your thoughts on an alternative. Many of the > > Apis are transport agnostic (Connect/Pair may end up connecting to > > either available transports for dual mode devices), but yet the error > > that results from them are not. Errors from one transport doesn't > > make sense for one and vice versa. A platform wanting to leverage > > telemetry and metrics to drive ecosystem improvements would ultimately > > need to know the difference even if the applications may not need to > > care. > > and we might have made a mistake in the API design and should have given the > caller more control. We need to review the API design and see if things > have to change. Just glueing things on at the end makes me suspicious. Some (5, wow!) years back I've loosely proposed split for org.bluez.Device API that was meant to handle some of the dual mode devices issues we've been seeing [1] [2]. We never got time to fully implement it (mostly due to hacking around device.c instead of properly splitting internal implementation into device_le.c and device_bredr.c) but got some very initial PoC running. With new interfaces old Device1 could be simply super-set of two for legacy applications purposes. Maybe such approach is worth re-considering? [1] https://marc.info/?l=linux-bluetooth&m=145710680912268&w=2 [2] https://marc.info/?l=linux-bluetooth&m=145973293118003&w=2 -- pozdrawiam Szymon Janc
