Bug#384379: [Pkg-bluetooth-maintainers] Bug#384379: WORK-AROUND for "iscan not set"

[Hendrik Sattler]

Am Sonntag 31 Dezember 2006 15:40 schrieb Marcel Holtmann:
> > The administrator should be able to change the default (visibility or
> > not) or there should be an always working default.
>
> The default is not visible (due security reasons) and if you decide it
> to switch it to visible (even with a low-level HCI command) it will only
> stay visible for 180 seconds. That is the default starting with 3.x.

Taking that...

> > That is currently not the case because the bluetooth guys change stuff
> > but the user frontends do catch up a bit late. Just remember the passkey
> > situation and this is pretty much the same. It probably gets solved in
> > the long run but that's a strange idea of development :-/
>
> It is actually solved for all GNOME and command line users. I don't know
> about the KDE guys, but I am sure they have something similar.

They don't, yet, users possibly have to wait for KDE4.
What is the solution for command line users? Or do you mean dbus-send?

> > Beside that, running the dbus command suggested in this bug report works,
> > too. It should be noted, though, that you have to be root.
>
> No. You have to be console user (or root).

Sorry but that is not sufficient. I tested this (X with konsole) and nothing 
happened. Running the same command with su worked.

> > It probably is the better alternative with exceptions:
> > * you cannot change the mode of devices that are currently not plugged in
>
> That is true. The case to change settings for not active devices is
> kinda strange. I know that there might be corner cases, but I never
> fully got convinced that this is needed.

* your last mode was "discoverable"
* you do not want to be visible
* plugging the dongle in and then chaning to "connectable" may be too late
Practically the same thing as the default from above.

> > * you can only refer to devices by using the device name, not the address
>
> Actually you can use "manager.FindAdapter(address)" to get the path for
> an adapter. Remember that the path for an adapter is only a string. It
> has no real meaning. You shouldn't trust that they stay the same.

So it is practically useless?

> > So is there an easy command line tool for all those dbus options (except
> > using raw dbus command)?: no == very bad usibility (and an awful lot to
> > type for one option)
> >
> > So how can you solve this problem with your input:
> > * ship the dbus API documenation in the binary packages
>
> Definitely.
>
> > * give the user and root a shell tool to make use of the things in the
> > bluez dbus API without getting bloody hands by using dbus-send
>
> Since we wanna avoid a Python dependency,

Does that mean that there is such a tool?

> I seems that there is finally 
> need for a btconfig tool written in plain C.

Or even better: write a libbluezconf with a shell frontend, so that other 
programs can easily change bluetooth settings.
Wouldn't a simply shell script suffice in the mean time?

HS