Hi,
There are some problems with the current D-BUS pin-request handling in
hcid. The attached patch tries to address those.
Also, the bluez-pin package will need to provide a D-BUS service file
(bluez.service) so that the D-BUS daemon can activate it when needed.
This file goes usually in /usr/lib/dbus-1.0/services and it's contents
should be something like the following:
[D-BUS Service]
Name=org.bluez.PinAgent
Exec=/usr/bin/bluez-pin
You'll also need the following line in /etc/dbus-1/system.conf (at least
the debian package of D-BUS doesn't have it):
<servicedir>/usr/lib/dbus-1.0/services</servicedir>
br,
Johan
On Thursday 17 June 2004 09:27, Sjoerd Simons wrote:
> On Wed, Jun 16, 2004 at 05:18:45PM +0300, Johan Hedberg wrote:
> > On Wed, Jun 16, 2004, Achim Bohnet wrote:
> > > On debian, dbus-1-utils installs a xsession startup script
> > > that checks for use-session-dbus in /etc/X11/Xsession.options
> > > Therefore dbus daemon knows the $DISPLAY.
>
> $DISPLAY is indeed in the enviroment when started by the debian x-session. But
> dbus doesn't (and shouldn't) care about it. There is nothing that says
> that a dbus session bus is connected to an X session (could be console
> only session just as well)..
As long is dbus does not delete DISPLAY it's okay ;) Child processes
inherit DISPLAY (if available) and that's the important point. In
hotplug scripts you have to hardcode :0 (almost always wrong when
someone works in a second session on :1) or implement hack to find
out the right display.
>
> > However, hcid uses the system D-BUS which knows nothing about the
> > session (system D-BUS and session D-BUS are run as two separate
> > processes). This is an interesting problem, because from a lowlevel
> > (BT-stack) standpoint we want to use the system bus, but from a higher
> > level (pin-code dialog) standpoint the session bus would be apropriate.
>
> From both standpoints you'll want to use the system bus. A bluetooth pin query
> is not linked to a specific users session, but to complete system.
>
> The current sollution is correct imho, when a users wants to answer pin
> queries he/she should have something running that monitors the system bus for
> them. That something could be a gnome applet/notification icon, a kde
> thingie or a simple command line program that doesn't really matter.
That does not scale well. Why does inetd exist? Just to not waste
resources. Something similar for the desktop should exist! We
have hotplug, on the one side and the desktop session on the other
side. Maybe the design of dbus is too limited (or simply not designed
for it). But AFAIK dbus can start apps on demand. So
hotplug -> system dbus -> session dbus -> desktop tool/applet
was (one of) my expectation of dbus. Makes no sense that every
app needs to know about dbus protocol, when all that's needed is
just a 'desktop inetd' that start or notifies, e.g. via DCOP, an
application off a certain hotplug event.
But this get's off really topic, I'll check the dbus mailing
lists ...
Achim
>
> The activation stuff could be nice for non-interactive pin handlers, but you
> can already use the ``old'' pin_helper option of hcid for that.
>
> Sjoerd
> --
> Men love to wonder, and that is the seed of science.
--
To me vi is Zen. To use vi is to practice zen. Every command is
a koan. Profound to the user, unintelligible to the uninitiated.
You discover truth everytime you use it.
-- [email protected]
On Wed, Jun 16, 2004 at 05:18:45PM +0300, Johan Hedberg wrote:
> On Wed, Jun 16, 2004, Achim Bohnet wrote:
> > On debian, dbus-1-utils installs a xsession startup script
> > that checks for use-session-dbus in /etc/X11/Xsession.options
> > Therefore dbus daemon knows the $DISPLAY.
$DISPLAY is indeed in the enviroment when started by the debian x-session. But
dbus doesn't (and shouldn't) care about it. There is nothing that says
that a dbus session bus is connected to an X session (could be console
only session just as well)..
> However, hcid uses the system D-BUS which knows nothing about the
> session (system D-BUS and session D-BUS are run as two separate
> processes). This is an interesting problem, because from a lowlevel
> (BT-stack) standpoint we want to use the system bus, but from a higher
> level (pin-code dialog) standpoint the session bus would be apropriate.
From both standpoints you'll want to use the system bus. A bluetooth pin query
is not linked to a specific users session, but to complete system.
The current sollution is correct imho, when a users wants to answer pin
queries he/she should have something running that monitors the system bus for
them. That something could be a gnome applet/notification icon, a kde
thingie or a simple command line program that doesn't really matter.
The activation stuff could be nice for non-interactive pin handlers, but you
can already use the ``old'' pin_helper option of hcid for that.
Sjoerd
--
Men love to wonder, and that is the seed of science.
Hi Johan,
> > > It would be nice to know how the D-BUS designers have thought about
> > > this kinds of problems.
> >
> > feel free to come up with a solution for this.
>
> Unfortunately I don't have one. Would it still be possible to add the
> dbus_message_set_auto_activation function call to the code? This will
> not change the behaviour in any way if the service is already aquired
> (i.e. bluez-pin is running), but will allow more flexibility if someone
> decides that they want to use D-BUS activation (for example in an
> embeded system where you only have one display and don't want to have
> unecessary processes taking up memory all the time).
right now I don't see where this helps. If you work embedded, you don't
need the D-Bus support. Use the old PIN helper stuff and write a shell
script or program that handles the input of the PINs.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
On Thu, Jun 17, 2004, Marcel Holtmann wrote:
> > It would be nice to know how the D-BUS designers have thought about
> > this kinds of problems.
>
> feel free to come up with a solution for this.
Unfortunately I don't have one. Would it still be possible to add the
dbus_message_set_auto_activation function call to the code? This will
not change the behaviour in any way if the service is already aquired
(i.e. bluez-pin is running), but will allow more flexibility if someone
decides that they want to use D-BUS activation (for example in an
embeded system where you only have one display and don't want to have
unecessary processes taking up memory all the time).
Johan
Hi Johan,
> > On debian, dbus-1-utils installs a xsession startup script
> > that checks for use-session-dbus in /etc/X11/Xsession.options
> > Therefore dbus daemon knows the $DISPLAY.
>
> However, hcid uses the system D-BUS which knows nothing about the
> session (system D-BUS and session D-BUS are run as two separate
> processes). This is an interesting problem, because from a lowlevel
> (BT-stack) standpoint we want to use the system bus, but from a higher
> level (pin-code dialog) standpoint the session bus would be apropriate.
>
> It would be nice to know how the D-BUS designers have thought about
> this kinds of problems.
feel free to come up with a solution for this.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wed, Jun 16, 2004, Achim Bohnet wrote:
> On debian, dbus-1-utils installs a xsession startup script
> that checks for use-session-dbus in /etc/X11/Xsession.options
> Therefore dbus daemon knows the $DISPLAY.
However, hcid uses the system D-BUS which knows nothing about the
session (system D-BUS and session D-BUS are run as two separate
processes). This is an interesting problem, because from a lowlevel
(BT-stack) standpoint we want to use the system bus, but from a higher
level (pin-code dialog) standpoint the session bus would be apropriate.
It would be nice to know how the D-BUS designers have thought about
this kinds of problems.
> Johan: When 2 xservers are running on vt7 as :0 and vt8 as :1
> respectively. Do the 2 dbus daemons know which one is active?
No idea. But probably not.
Johan
Hi Johan,
> > if we change it this way, then how do the D-Bus PIN Helper get its
> > information about the running X server?
>
> Good question ;-). One option is to hardcode DISPLAY=:0 to the
> pin-helper. Another one (probably better) is to start the D-BUS daemon
> with some default DISPLAY environment variable (which its child
> processes will inherit). How is this done with the old pin-helper
> design where hcid execs the pin-helper?
this was exactly the problem with old PIN helper and this is why the
D-Bus version should be started from .xession user script.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wednesday 16 June 2004 15:06, Marcel Holtmann wrote:
> Hi Johan,
>
> > I must admit that I hadn't looked into how the bluez-pin program works
> > in D-BUS mode. It seems it should be running all the time to be able to
> > receive any D-BUS requests, correct?
> >
> > The service activation feature of D-BUS which I have talked about is
> > designed to solve the problem where some D-BUS service should be
> > launched on-demand. I think the pin-helper falls exactly into this
> > category, and would be IMHO more elegant if it wouldn't have to be
> > running all the time but would be automatically launched by D-BUS daemon
> > when needed.
Agreed.
> if we change it this way, then how do the D-Bus PIN Helper get its
> information about the running X server?
On debian, dbus-1-utils installs a xsession startup script
that checks for use-session-dbus in /etc/X11/Xsession.options
Therefore dbus daemon knows the $DISPLAY.
Johan: When 2 xservers are running on vt7 as :0 and vt8 as :1
respectively. Do the 2 dbus daemons know which one is active?
(i.e. crt or lcd currently displays :0 or :1) Would be nice to
get the pin helper window on :1 if one is working there instead
of on :0 ;)
Achim
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
>
>
--
To me vi is Zen. To use vi is to practice zen. Every command is
a koan. Profound to the user, unintelligible to the uninitiated.
You discover truth everytime you use it.
-- [email protected]
On Wed, Jun 16, 2004, ext Marcel Holtmann wrote:
> if we change it this way, then how do the D-Bus PIN Helper get its
> information about the running X server?
Good question ;-). One option is to hardcode DISPLAY=:0 to the
pin-helper. Another one (probably better) is to start the D-BUS daemon
with some default DISPLAY environment variable (which its child
processes will inherit). How is this done with the old pin-helper
design where hcid execs the pin-helper?
Johan
Hi Johan,
> I must admit that I hadn't looked into how the bluez-pin program works
> in D-BUS mode. It seems it should be running all the time to be able to
> receive any D-BUS requests, correct?
>
> The service activation feature of D-BUS which I have talked about is
> designed to solve the problem where some D-BUS service should be
> launched on-demand. I think the pin-helper falls exactly into this
> category, and would be IMHO more elegant if it wouldn't have to be
> running all the time but would be automatically launched by D-BUS daemon
> when needed.
if we change it this way, then how do the D-Bus PIN Helper get its
information about the running X server?
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
I must admit that I hadn't looked into how the bluez-pin program works
in D-BUS mode. It seems it should be running all the time to be able to
receive any D-BUS requests, correct?
The service activation feature of D-BUS which I have talked about is
designed to solve the problem where some D-BUS service should be
launched on-demand. I think the pin-helper falls exactly into this
category, and would be IMHO more elegant if it wouldn't have to be
running all the time but would be automatically launched by D-BUS daemon
when needed.
On Wed, Jun 16, 2004, ext Marcel Holtmann wrote:
> > The second part (dbus_message_set_auto_activation) enables service
> > activation if the PinAgent service isn't aquired by any process (i.e.
> > the D-BUS daemon will execute the pin-helper program if needed).
>
> The hcid shouldn't execute the D-Bus PIN helper.
Not hcid, but the D-BUS daemon.
> From my local .xession I start "bluez-pin --dbus &" and everything works
> fine.
Ok. But by using D-BUS service activation, you wouldn't need to do this.
Johan
Hi Johan,
> The first part with the error handling is needed because
> dbus_pending_call_get_reply() may return NULL if a timeout occurs (a
> reply isn't received in time). Also, if new errors are added in the
> future it is probably better to check for the general case here:
> dbus_message_get_type().
ok, but the "message == NULL" must be moved into the D-Bus library. I
checked their source code and actually they miss a
_dbus_return_val_if_fail (message != NULL, ???);
in their function.
> The second part (dbus_message_set_auto_activation) enables service
> activation if the PinAgent service isn't aquired by any process (i.e.
> the D-BUS daemon will execute the pin-helper program if needed).
The hcid shouldn't execute the D-Bus PIN helper. In case of a failure
with the D-Bus version it should fall back to the old one.
> Do you mean that without these changes, the pin-helper is automatically
> launched when a D-BUS message is sent by hcid to the service
> org.bluez.PinAgent? I could not get it working without the changes. What
> version of D-BUS are you using?
I use these tools:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii bluez-hcidump 1.5-2 Analyses Bluetooth HCI packets
ii bluez-pin 0.23-1 Bluetooth PIN helper with D-BUS support
ii bluez-utils 2.7-4 Bluetooth tools and daemons
And I set this in hcid.conf:
# PIN helper
pin_helper /usr/bin/bluez-pin;
# D-Bus PIN helper
dbus_pin_helper;
>>From my local .xession I start "bluez-pin --dbus &" and everything works
fine.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wed, Jun 16, 2004, Johan Hedberg wrote:
> Also, if new errors are added in the future it is probably better to
> check for the general case here: dbus_message_get_type().
Actually you might even now get some DBUS_ERROR_* from
dbus_pending_call_get_reply (for example DBUS_ERROR_NO_REPLY), so
the dbus_message_get_type() == ERROR test is needed anyway.
Johan
On Wed, Jun 16, 2004, Marcel Holtmann wrote:
> since I don't know very much about D-Bus, please explain your changes to
> me. Why are they needed?
The first part with the error handling is needed because
dbus_pending_call_get_reply() may return NULL if a timeout occurs (a
reply isn't received in time). Also, if new errors are added in the
future it is probably better to check for the general case here:
dbus_message_get_type().
The second part (dbus_message_set_auto_activation) enables service
activation if the PinAgent service isn't aquired by any process (i.e.
the D-BUS daemon will execute the pin-helper program if needed).
> Don't get your point here, because it works perfect on my Debian Sid.
Do you mean that without these changes, the pin-helper is automatically
launched when a D-BUS message is sent by hcid to the service
org.bluez.PinAgent? I could not get it working without the changes. What
version of D-BUS are you using?
Johan
Hi Johan,
> There are some problems with the current D-BUS pin-request handling in
> hcid. The attached patch tries to address those.
since I don't know very much about D-Bus, please explain your changes to
me. Why are they needed?
> Also, the bluez-pin package will need to provide a D-BUS service file
> (bluez.service) so that the D-BUS daemon can activate it when needed.
> This file goes usually in /usr/lib/dbus-1.0/services and it's contents
> should be something like the following:
>
> [D-BUS Service]
> Name=org.bluez.PinAgent
> Exec=/usr/bin/bluez-pin
>
> You'll also need the following line in /etc/dbus-1/system.conf (at least
> the debian package of D-BUS doesn't have it):
> <servicedir>/usr/lib/dbus-1.0/services</servicedir>
Don't get your point here, because it works perfect on my Debian Sid.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel