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

[Marcel Holtmann]

Hi Hendrik,

> > > 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?

basically you have dbus-send. Additionally we have our apitest script
that we used for testing the interface. However it might not be suitable
for a general installation.

> > > 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.

That must be a bug of the at_console setting of D-Bus. We really on the
security system of D-Bus here. And the general (actually default rule)
is that root and the current console user can change all settings.

> > > 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.

This is why we go back to non-discoverable after 180 seconds by default.

Supporting these kind of strange setting would also mean that you know
the address of the adapter you are gonna plug in up-front. In general
you don't. Except you really know what you are doing and then no
interface will fully suit you at all.

> > > * 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?

It is not useless. It is meaningless, because it is a runtime value. As
long as the adapter is plugged in it is valid, but after that it has no
additional lexical meaning.

This is why "manager.ListAdapters()" and "manager.DefaultAdapter()"
exists to discover the adapters.

> > > 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?

The apitest script could easily do this job or the dbusdef.py pre-load
code are really helpful for testing. In general it is really simple to
handle our D-Bus API from within Python. Most things are only a few
lines of Python, but for a base package like bluez-utils you don't wanna
have that dependency.

> > 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.

This always comes up from time to time, but wrapping another C API
around the D-Bus API is really not a good idea. You wanna use D-Bus
directly and fully integrate it.

> Wouldn't a simply shell script suffice in the mean time?

Using dbus-send only? Yes, that would do.

Regards

Marcel