Hi guys,
I always said that the D-Bus interface won't have to be designed after
any technical part of the Bluetooth specification and I think it is time
to change the discoverable and connectable options.
The Bluetooth specification and most devices allow you to set the device
to discoverable, but not connectable. The combination actually makes no
sense at all, because for the name resolving the remote device must be
connectable. I would propose to have a "mode" property with actually
three different states: Off, Connectable, Discoverable/Connectable. The
Off state also makes the Up/Down functions obsolete, because they are
BlueZ internal and in some embedded devices you might wanna also have
deep sleep mode support. The internals should be all hidden from the
userspace and for desktop devices the Off option could mean inquiry and
page scan disabled.
The other option that is needed is of course the device name. With the
upcoming extended inquiry the question is now if we also wanna support a
short name or if hcid/bluetoothd should shorten the name by itself if
needed.
We also have to deal with the major and minor part of the device class.
The other bits would be set by sdpd if a specific profile has been
registered.
What else needs to be configurable?
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,
> > do you mean have both implementations (SetProperty("mode") and SetMode) ?
>
> we can have both, but I would prefer the SetMode() stuff.
and if a device is in Connectable only mode it would be great if we have
another method that makes this device discoverable for a specific time.
For example make it discoverable for 3 minutes, like the early Ericsson
phones did.
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,
> do you mean have both implementations (SetProperty("mode") and SetMode) ?
we can have both, but I would prefer the SetMode() stuff.
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 Marcel,
do you mean have both implementations (SetProperty("mode") and SetMode) ?
BR,
Eduardo.
On 12/22/05, Marcel Holtmann <[email protected]> wrote:
> Hi Eduardo,
>
> > any suggestion about Discoverable/Connectable parameter string? Maybe =
"Full" ?
>
> besides the property thing, I like to see something like:
>
> SetMode(uint8 mode) [Method]
> uint8 GetMode() [Method]
> ModeChanged(uint8) [Signal]
>
> mode 0x00 =3D Off (means down or deep-sleep)
> mode 0x01 =3D Connectable
> mode 0x02 =3D Connectable and Discoverable
>
> What do you thing?
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> 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=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
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 Eduardo,
> any suggestion about Discoverable/Connectable parameter string? Maybe "Full" ?
besides the property thing, I like to see something like:
SetMode(uint8 mode) [Method]
uint8 GetMode() [Method]
ModeChanged(uint8) [Signal]
mode 0x00 = Off (means down or deep-sleep)
mode 0x01 = Connectable
mode 0x02 = Connectable and Discoverable
What do you thing?
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 Marcel,
any suggestion about Discoverable/Connectable parameter string? Maybe "Ful=
l" ?
BR,
Eduardo.
On 12/21/05, Marcel Holtmann <[email protected]> wrote:
> Hi Eduardo,
>
> > I agree about the "mode" property. But about Up and Down we have to
> > consider issues like security and power save. Will the Off mode
> > (nopiscan) be equivalent to device Down in power consumption?
>
> this is implementation specific. On some embedded devices, this might be
> the same as deep-sleep. Others might disconnect the device from the bus
> or simply call down. The user interface shouldn't have to care about it.
>
> I think that we also need something like a status which shows if the
> device is idle, running an inquiry or have active connections.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> 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=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
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 Eduardo,
> I agree about the "mode" property. But about Up and Down we have to
> consider issues like security and power save. Will the Off mode
> (nopiscan) be equivalent to device Down in power consumption?
this is implementation specific. On some embedded devices, this might be
the same as deep-sleep. Others might disconnect the device from the bus
or simply call down. The user interface shouldn't have to care about it.
I think that we also need something like a status which shows if the
device is idle, running an inquiry or have active connections.
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 Marcel,
I agree about the "mode" property. But about Up and Down we have to
consider issues like security and power save. Will the Off mode
(nopiscan) be equivalent to device Down in power consumption?
BR,
Eduardo.
On 12/20/05, Marcel Holtmann <[email protected]> wrote:
> Hi guys,
>
> I always said that the D-Bus interface won't have to be designed after
> any technical part of the Bluetooth specification and I think it is time
> to change the discoverable and connectable options.
>
> The Bluetooth specification and most devices allow you to set the device
> to discoverable, but not connectable. The combination actually makes no
> sense at all, because for the name resolving the remote device must be
> connectable. I would propose to have a "mode" property with actually
> three different states: Off, Connectable, Discoverable/Connectable. The
> Off state also makes the Up/Down functions obsolete, because they are
> BlueZ internal and in some embedded devices you might wanna also have
> deep sleep mode support. The internals should be all hidden from the
> userspace and for desktop devices the Off option could mean inquiry and
> page scan disabled.
>
> The other option that is needed is of course the device name. With the
> upcoming extended inquiry the question is now if we also wanna support a
> short name or if hcid/bluetoothd should shorten the name by itself if
> needed.
>
> We also have to deal with the major and minor part of the device class.
> The other bits would be set by sdpd if a specific profile has been
> registered.
>
> What else needs to be configurable?
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> 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=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
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 Marcel,
Here is the patch following your suggestion.
Now, we introduced a problem. How handle scenarios where other
application/or hciconfig changes the scan mode, enabling the Inquiry
Scan only? :) In the current patch, I am ignoring the HCI command
complete event for this case.
When we close this discussion I can start play with the discoverable time stuff.
Regards,
Claudio.
On 1/26/06, Marcel Holtmann <[email protected]> wrote:
> Hi Claudio,
>
> > This patch is based on your discussion, but there are some changes:
> > 1. The scan enable values are based on the Bluetooth Spec in order to
> > make the logic more clear:
> > mode 0x00 = Off (means down or deep-sleep)
> > mode 0x01 = Discoverable (NOT ALLOWED)
> > mode 0x02 = Connectable
> > mode 0x03 = Connectable and Discoverable
>
> actually I didn't used the values from the specification on purpose. On
> future idea is that we support discoverable for them time and the client
> doesn't have to take care when to switch inquiry scan off again. As I
> sometimes mentioned, it might be good to not follow the specification
> for the D-Bus API. The hcid/bluetoothd will hide all implementation
> details.
>
> 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT
Hi Claudio,
> This patch is based on your discussion, but there are some changes:
> 1. The scan enable values are based on the Bluetooth Spec in order to
> make the logic more clear:
> mode 0x00 = Off (means down or deep-sleep)
> mode 0x01 = Discoverable (NOT ALLOWED)
> mode 0x02 = Connectable
> mode 0x03 = Connectable and Discoverable
actually I didn't used the values from the specification on purpose. On
future idea is that we support discoverable for them time and the client
doesn't have to take care when to switch inquiry scan off again. As I
sometimes mentioned, it might be good to not follow the specification
for the D-Bus API. The hcid/bluetoothd will hide all implementation
details.
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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi guys,
This patch is based on your discussion, but there are some changes:
1. The scan enable values are based on the Bluetooth Spec in order to
make the logic more clear:
mode 0x00 = Off (means down or deep-sleep)
mode 0x01 = Discoverable (NOT ALLOWED)
mode 0x02 = Connectable
mode 0x03 = Connectable and Discoverable
2. SetProperty/GetProperty can be used to set/get scan value
According with the previous discussion, we can have both, but
SetMode/GetMode is the preferred approach. This patch support only
SetMode/GetMode. Support both approachs will make the code messy!
Testing sample:
//SetMode sample the allowed values are: 0, 2 and 3
$dbus-send --system --print-reply --dest=org.bluez
/org/bluez/Device/hci0 org.bluez.Device.SetMode byte:0
//GetMode sample
$dbus-send --system --print-reply --dest=org.bluez
/org/bluez/Device/hci0 org.bluez.Device.GetMode
The dbus-test python script can be used too.
Regards,
Claudio.
On 12/24/05, Marcel Holtmann <[email protected]> wrote:
> Hi Eduardo,
>
> > > do you mean have both implementations (SetProperty("mode") and SetMode) ?
> >
> > we can have both, but I would prefer the SetMode() stuff.
>
> and if a device is in Connectable only mode it would be great if we have
> another method that makes this device discoverable for a specific time.
> For example make it discoverable for 3 minutes, like the early Ericsson
> phones did.
>
> 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
>
--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT
Hi Claudio,
> here is the new patch!
>
> You can use the command below or the dbus-test script to test this feature.
> $dbus-send --system --print-reply --type=method_call --dest=org.bluez
> /org/bluez/Device/hci0 org.bluez.Device.SetMode byte:0
>
> $dbus-send --system --print-reply --type=method_call --dest=org.bluez
> /org/bluez/Device/hci0 org.bluez.Device.GetMode
the patch has been applied to the CVS now.
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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
here is the new patch!
You can use the command below or the dbus-test script to test this feature.
$dbus-send --system --print-reply --type=method_call --dest=org.bluez
/org/bluez/Device/hci0 org.bluez.Device.SetMode byte:0
$dbus-send --system --print-reply --type=method_call --dest=org.bluez
/org/bluez/Device/hci0 org.bluez.Device.GetMode
I will send tomorrow a new version of the GBlueZConf with this feature.
Regards,
Claudio.
On 2/2/06, Marcel Holtmann <[email protected]> wrote:
> Hi Claudio,
>
> > Here is the patch following your suggestion.
>
> cool, but the patch has some issues.
>
> Don't refer to the Bluetooth specification for the mode values, because
> we define our own.
>
> Please name the modes like following:
>
> #define MODE_OFF 0x00
> #define MODE_CONNECTABLE 0x01
> #define MODE_DISCOVERABLE 0x02
>
> The discoverable mode of course includes connectable mode.
>
> In the handle_device_get_mode_req(), the switch statement always sets
> the mode to 0xff. Please add the breaks and if you write a fall through
> statement, then comment it.
>
> > Now, we introduced a problem. How handle scenarios where other
> > application/or hciconfig changes the scan mode, enabling the Inquiry
> > Scan only? :) In the current patch, I am ignoring the HCI command
> > complete event for this case.
>
> We need to track the scan mode command complete event and if the mode
> changes, we need to send out a mode change signal.
>
> > When we close this discussion I can start play with the discoverable time stuff.
>
> That would be really great, because this feature could come in handy for
> any graphical application.
>
> 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT
Hi Claudio,
> Here is the patch following your suggestion.
cool, but the patch has some issues.
Don't refer to the Bluetooth specification for the mode values, because
we define our own.
Please name the modes like following:
#define MODE_OFF 0x00
#define MODE_CONNECTABLE 0x01
#define MODE_DISCOVERABLE 0x02
The discoverable mode of course includes connectable mode.
In the handle_device_get_mode_req(), the switch statement always sets
the mode to 0xff. Please add the breaks and if you write a fall through
statement, then comment it.
> Now, we introduced a problem. How handle scenarios where other
> application/or hciconfig changes the scan mode, enabling the Inquiry
> Scan only? :) In the current patch, I am ignoring the HCI command
> complete event for this case.
We need to track the scan mode command complete event and if the mode
changes, we need to send out a mode change signal.
> When we close this discussion I can start play with the discoverable time stuff.
That would be really great, because this feature could come in handy for
any graphical application.
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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel