Hi Marcel, Johan and Claudio,
I'm going to start the scan property implementation for device path
now. From early discussions, I think we have agreeded to split page
scan and inquire scan property. Starting to think in implementation
now, I realized that this imply in an extra getdeviceinfo, as we have
to now if the exactly page flag status to modify it. If we join this
two properties into scan property, with 2 boolean parameters for pscan
and iscan, we can eliminate this operation. What do you guys think?
BR,
Eduardo.
--
Eduardo Rocha
Instituto Nokia de Tecnologia - INdT
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Johan,
> > I'm going to start the scan property implementation for device path
> > now. From early discussions, I think we have agreeded to split page
> > scan and inquire scan property. Starting to think in implementation
> > now, I realized that this imply in an extra getdeviceinfo, as we have
> > to now if the exactly page flag status to modify it. If we join this
> > two properties into scan property, with 2 boolean parameters for pscan
> > and iscan, we can eliminate this operation. What do you guys think?
>
> I think we should have two boolean properties: "discoverable" and
> "connectable", even if that means doing an extra HCI_Read_Scan_Enable
> command when setting the value of either one.
I agree here. The goal is to define a better API and not to reproduce
the HCI. If this means we have to read the value before modifying it
than we must live with it. Anyhow this is an implementation detail.
In general the kernel is capable of tracking this value, but lately I
have seen some problems with it. Once our D-Bus interface is stable, we
can think about what the kernel can do to help us out here.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Eduardo,
On Fri, Nov 25, 2005, Eduardo Rocha wrote:
> I'm going to start the scan property implementation for device path
> now. From early discussions, I think we have agreeded to split page
> scan and inquire scan property. Starting to think in implementation
> now, I realized that this imply in an extra getdeviceinfo, as we have
> to now if the exactly page flag status to modify it. If we join this
> two properties into scan property, with 2 boolean parameters for pscan
> and iscan, we can eliminate this operation. What do you guys think?
I think we should have two boolean properties: "discoverable" and
"connectable", even if that means doing an extra HCI_Read_Scan_Enable
command when setting the value of either one.
Johan
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel