Hi Santiago and Elvis,
Read clock is not implemented in the management interface. Does it
break something important in the health plug-in?
I am not aware when hciops will be dropped, but the fact is: if the
system uses mgmtops instead of hciops health will not work properly.
BR,
Claudio.
Hi Gustavo,
On Thu, Jun 9, 2011 at 4:09 PM, Gustavo F. Padovan
<[email protected]> wrote:
> * Elvis Pfutzenreuter <[email protected]> [2011-06-09 09:42:42 -0300]:
>
>> On Jun 9, 2011, at 9:28 AM, Johan Hedberg wrote:
>>
>> > Hi,
>> >
>> > On Thu, Jun 09, 2011, Elvis Pfutzenreuter wrote:
>> >>> Coming back to this issue. I'm not caught up with this stuff and I
>> >>> dont know if there are any special reason to not provide a read clock
>> >>> functionality in the bluetooth API. although I think it's a pity to
>> >>> restrict MCAP features after the good work Elvis did in CSP.
>> >>
>> >> More to the point, could we implement HCI read clock for mgmt interface? Or
>> >> it simply won't have read clock by design?
>> >
>> > There's no obvious reason why it couldn't have it. However other means
>> > should be considered too, e.g. would it be cleaner to get the info
>> > directly through the socket (using a socket option or something
>> > similar)? Or was this already considered when the HCI socket solution
>> > was implemented?
>>
>> Not exactly, I just made use of hci_read_clock() that already existed in BlueZ
>> API, and copied the code into hciops.
>>
>> Getting clock via a socket option sounds better to me since a) we need
>> connection ACL to read it, getting it through a L2CAP socket would imply the
>> ACL; b) it would allow other apps to use the feature (e.g. PyBluez that
>> currently reads clock using an HCI socket).
>
> Getting it from a L2CAP socket does not seems right. If you want to read a
> clock value, probably the ACL link is already there. Implement this on
> the management interface is the best option.
>
> Gustavo
>
We gonna need a similar approach to read the Tx Power and RSSI of an active
connection to implement the Proximity Profile(Path Loss Service). It'd
be good to
keep consistency, using the same approach if possible.
What are your arguments against L2CAP socket options? Blocking: wait
for response
of the HCI commands. Something else?
If we agree to use management interface I think we need to add another
channel, use
HCI_CHANNEL_CONTROL doesn't look correct to me.
BR,
Claudio.
* Elvis Pfutzenreuter <[email protected]> [2011-06-09 09:42:42 -0300]:
> On Jun 9, 2011, at 9:28 AM, Johan Hedberg wrote:
>
> > Hi,
> >
> > On Thu, Jun 09, 2011, Elvis Pfutzenreuter wrote:
> >>> Coming back to this issue. I'm not caught up with this stuff and I
> >>> dont know if there are any special reason to not provide a read clock
> >>> functionality in the bluetooth API. although I think it's a pity to
> >>> restrict MCAP features after the good work Elvis did in CSP.
> >>
> >> More to the point, could we implement HCI read clock for mgmt interface? Or
> >> it simply won't have read clock by design?
> >
> > There's no obvious reason why it couldn't have it. However other means
> > should be considered too, e.g. would it be cleaner to get the info
> > directly through the socket (using a socket option or something
> > similar)? Or was this already considered when the HCI socket solution
> > was implemented?
>
> Not exactly, I just made use of hci_read_clock() that already existed in BlueZ
> API, and copied the code into hciops.
>
> Getting clock via a socket option sounds better to me since a) we need
> connection ACL to read it, getting it through a L2CAP socket would imply the
> ACL; b) it would allow other apps to use the feature (e.g. PyBluez that
> currently reads clock using an HCI socket).
Getting it from a L2CAP socket does not seems right. If you want to read a
clock value, probably the ACL link is already there. Implement this on
the management interface is the best option.
Gustavo
On Jun 9, 2011, at 9:28 AM, Johan Hedberg wrote:
> Hi,
>
> On Thu, Jun 09, 2011, Elvis Pfutzenreuter wrote:
>>> Coming back to this issue. I'm not caught up with this stuff and I
>>> dont know if there are any special reason to not provide a read clock
>>> functionality in the bluetooth API. although I think it's a pity to
>>> restrict MCAP features after the good work Elvis did in CSP.
>>
>> More to the point, could we implement HCI read clock for mgmt interface? Or
>> it simply won't have read clock by design?
>
> There's no obvious reason why it couldn't have it. However other means
> should be considered too, e.g. would it be cleaner to get the info
> directly through the socket (using a socket option or something
> similar)? Or was this already considered when the HCI socket solution
> was implemented?
Not exactly, I just made use of hci_read_clock() that already existed in BlueZ
API, and copied the code into hciops.
Getting clock via a socket option sounds better to me since a) we need
connection ACL to read it, getting it through a L2CAP socket would imply the
ACL; b) it would allow other apps to use the feature (e.g. PyBluez that
currently reads clock using an HCI socket).
Hi,
On Thu, Jun 09, 2011, Elvis Pfutzenreuter wrote:
> > Coming back to this issue. I'm not caught up with this stuff and I
> > dont know if there are any special reason to not provide a read clock
> > functionality in the bluetooth API. although I think it's a pity to
> > restrict MCAP features after the good work Elvis did in CSP.
>
> More to the point, could we implement HCI read clock for mgmt interface? Or
> it simply won't have read clock by design?
There's no obvious reason why it couldn't have it. However other means
should be considered too, e.g. would it be cleaner to get the info
directly through the socket (using a socket option or something
similar)? Or was this already considered when the HCI socket solution
was implemented?
Johan
On Jun 9, 2011, at 6:48 AM, Santiago Carot wrote:
> Hi.
>
> 2011/6/8 Santiago Carot <[email protected]>:
>> Hello Claudio.
>>
>> 2011/6/8 Claudio Takahasi <[email protected]>:
>>> Hi Santiago and Elvis,
>>>
>>> Read clock is not implemented in the management interface. Does it
>>> break something important in the health plug-in?
>>>
>
> Coming back to this issue. I'm not caught up with this stuff and I
> dont know if there are any special reason to not provide a read clock
> functionality in the bluetooth API. although I think it's a pity to
> restrict MCAP features after the good work Elvis did in CSP.
More to the point, could we implement HCI read clock for mgmt interface? Or
it simply won't have read clock by design?
Hi.
2011/6/8 Santiago Carot <[email protected]>:
> Hello Claudio.
>
> 2011/6/8 Claudio Takahasi <[email protected]>:
>> Hi Santiago and Elvis,
>>
>> Read clock is not implemented in the management interface. Does it
>> break something important in the health plug-in?
>>
Coming back to this issue. I'm not caught up with this stuff and I
dont know if there are any special reason to not provide a read clock
functionality in the bluetooth API. although I think it's a pity to
restrict MCAP features after the good work Elvis did in CSP.
Regards.
>
> Read clock is only required for Clock Shynchronization Protocol (CSP)
> in MCAP, but ?CSP is not mandatory for HDP and although this feature
> was implemented in MCAP is not used in the Health Plugin so it won't
> break the API.
>
>> I am not aware when hciops will be dropped, but the fact is: if the
>> system uses mgmtops instead of hciops health will not work properly.
>>
>
> Well, as far as I know, only MCAP uses it for CSP and it's an optional
> part in the specification so it won't a severe problem for health
> applications.
>
>> BR,
>> Claudio.
>>
>
Hello Claudio.
2011/6/8 Claudio Takahasi <[email protected]>:
> Hi Santiago and Elvis,
>
> Read clock is not implemented in the management interface. Does it
> break something important in the health plug-in?
>
Read clock is only required for Clock Shynchronization Protocol (CSP)
in MCAP, but CSP is not mandatory for HDP and although this feature
was implemented in MCAP is not used in the Health Plugin so it won't
break the API.
> I am not aware when hciops will be dropped, but the fact is: if the
> system uses mgmtops instead of hciops health will not work properly.
>
Well, as far as I know, only MCAP uses it for CSP and it's an optional
part in the specification so it won't a severe problem for health
applications.
> BR,
> Claudio.
>