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

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

[Mat Martineau]

Johan -

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.

--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum

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

[Johan Hedberg]

Hi Mat,

On Fri, Jan 13, 2012, Mat Martineau wrote:
> 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.

Johan

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

[Marcel Holtmann]

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.

Regards

Marcel

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

[Mat Martineau]

Hi Johan -

On Mon, 16 Jan 2012, Marcel Holtmann wrote:

> 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.


--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum

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

[Johan Hedberg]

Hi Mat,

On Mon, Jan 16, 2012, Mat Martineau wrote:
> >>>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.

If something like that is really needed then I think some sort of a
socket option might make more sense, i.e. the application could call
getsockopt (or some higher level wrapper like BtIO) to figure this out.
In any case it's not enough for the remote device to support EDR if the
local device isn't capable of it.

Johan

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

[Marcel Holtmann]

Hi Johan,

> > >>>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.
> 
> If something like that is really needed then I think some sort of a
> socket option might make more sense, i.e. the application could call
> getsockopt (or some higher level wrapper like BtIO) to figure this out.
> In any case it's not enough for the remote device to support EDR if the
> local device isn't capable of it.

if we look a little bit ahead of this and trying to do this right, then
we better add some SCM data that indicates what our current possible
bandwidth might be. And we do that while receiving a packet and not with
some socket option. We just have to enable it via a socket option. This
could account for BR or EDR or even HS and in case it changes on the
fly. I am pretty sure I mentioned this already some time before.

The only real bummer is that the BR/EDR packet mask is just a simple
indication that we are giving to the controller. It does not mean that
it will always give us the maximum bandwidth possible. Especially if we
also have SCO connection open.

Most likely still better than magically assuming something based on the
remote LMP version ;)

Regards

Marcel

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

[Marcel Holtmann]

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