Hi Mat, > >>> I noticed your recent bluez.git commit that modifies the Device > >>> Connected event. Would it also make sense to add the results of the > >>> READ_REMOTE_VERSION command? > >>> > >>> lmp_ver > >>> manufacturer > >>> lmp_subver > >>> > >>> This information was captured in bluetoothd when using hciops, but > >>> has so far been missing with mgmtops. > >> > >> Do you have a real use-case for it? It'd expect that info to be at most > >> useful to the kernel side but not so much for user-space. FWIW, we came > >> to the conclusion with Marcel that a better approach with this > >> mgmt_ev_device_connected is to encode both the class and the name as an > >> EIR blob. We'll also do that for the class that's currently as a > >> separate parameter in mgmt_ev_device_found. This simplifies the > >> structure of both events and also allows for future extensibility. > > > > in addition, these information are purely debugging details and I think > > it would be better to use sysfs or debugfs for it. > > The use case involves checking the remote LMP version to figure out if > the remote device supports EDR, to get a rough estimate of available > bandwidth. Lower bandwidth devices can then use different settings at > the profile or application layer. I can see your point here, but that check is wrong way in achieving this. Such a thing needs to be done a) via supported features and b) via the actual allowed packets. Looking at remote LMP version is wrong. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html