linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [Bluez-devel] Device scan property
@ 2005-11-25 14:43 Eduardo Rocha
  2005-11-25 14:56 ` Johan Hedberg
  0 siblings, 1 reply; 3+ messages in thread
From: Eduardo Rocha @ 2005-11-25 14:43 UTC (permalink / raw)
  To: bluez-devel

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Bluez-devel] Device scan property
  2005-11-25 14:43 [Bluez-devel] Device scan property Eduardo Rocha
@ 2005-11-25 14:56 ` Johan Hedberg
  2005-11-25 19:04   ` Marcel Holtmann
  0 siblings, 1 reply; 3+ messages in thread
From: Johan Hedberg @ 2005-11-25 14:56 UTC (permalink / raw)
  To: 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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Bluez-devel] Device scan property
  2005-11-25 14:56 ` Johan Hedberg
@ 2005-11-25 19:04   ` Marcel Holtmann
  0 siblings, 0 replies; 3+ messages in thread
From: Marcel Holtmann @ 2005-11-25 19:04 UTC (permalink / raw)
  To: 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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2005-11-25 19:04 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-25 14:43 [Bluez-devel] Device scan property Eduardo Rocha
2005-11-25 14:56 ` Johan Hedberg
2005-11-25 19:04   ` Marcel Holtmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).