Re: As long as we're adding to the Device Connected mgmt event...

[Marcel Holtmann <marcel@holtmann.org>]

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