Bug #23612 for Net-DBus: No Signals From HAL

Sat Nov 25 11:48:12 2006 tony [...] awtrey.com - Ticket created

Subject:

No Signals From HAL

The signal handler seems to be broken in the current release, at least in regards to the HAL daemon on Debian Etch. I've been trying to get simple device detection to work for a couple of days now and have introspected and dumped until I can't think of anything else to try. I've written what should be a simple prototype script to use the Net::DBus module to get signals emitted from the HAL. What I can't figure out is how the example signal emitter/receiver applications work, but nearly the exact same code with the HAL does not. One symptom of this bug that seems important is that the introspector / dumper lists no signals when viewing the HAL interface, but does correctly list all of its available methods. I've spent about 4 hours tracing code paths, but I just don't know enough about the dbus library to be much help. I've attached an example script that should work for simple device detection, but since the Manager does not appear to be aware of any signals to watch, nothing ever happens when devices are inserted or removed. I'm running Debian Etch, 2.6.18 kernel, dbus-0.94-1, hal-0.5.8.1-4 and libnet-dbus-perl-0.33.4-1. Any help would be greatly appreciated. Thanks! Tony

Sat Nov 25 11:49:16 2006 tony [...] awtrey.com - Correspondence added

Subject:	Forgot the attachment...
From:	tony [...] awtrey.com

Here goes! T

#!/usr/bin/perl use strict; use warnings; use Net::DBus; use Net::DBus::Reactor; use Net::DBus::Callback; use Net::DBus::Dumper; my $bus = Net::DBus->system; my $hal = $bus->get_service("org.freedesktop.Hal"); my $manager = $hal->get_object("/org/freedesktop/Hal/Manager", "org.freedesktop.Hal.Manager"); print Net::DBus::Dumper::dbus_dump($manager); $manager->connect_to_signal( 'DeviceAdded', sub{ print "DeviceAdded\n"; } ); $manager->connect_to_signal( 'DeviceRemoved', sub{ print "DeviceRemoved\n"; } ); $manager->connect_to_signal( 'NewCapability', sub{ print "NewCapability\n"; } ); my $reactor = Net::DBus::Reactor->new(); my $tid = $reactor->add_timeout(1000, Net::DBus::Callback->new( method => sub{ print "... tick ...\n"; }, args => [] ), 1); $reactor->run(); # End

Sat Nov 25 17:32:03 2006 dan [...] berrange.com - Correspondence added

On Sat Nov 25 11:49:16 2006, DaGoodBoy wrote: Show quoted text

> Here goes! > > T

I've run the test case & successfully reproduced the behaviour you are seeing. The test case has a little bug in that its calling the 'new' method on the Net::DBus::Reactor, rather the 'main' method - this creates a new reactor, rather than using the singleton instance. I can see how the documentation is a little misleading in this regard so will clarify it. Once that is corrected though, there is clearly still a problem here. The HAL service is providing incomplete introspection data - the Net::DBus bindings expect either complete data, or no introspection data at all - the half-complete data is causing problems. It looks fairly straightforward to change the bindings to deal with half-complete data which will fix this example test case with HAL. Will aim to get this fix into the next (probably 0.33.5) release

Sat Nov 25 17:32:04 2006 The RT System itself - Status changed from 'new' to 'open'

Wed Jul 18 23:20:39 2007 dan [...] berrange.com - Correspondence added

The new 0.33.5 release of Net-DBus has a re-written the code for handling Introspection data. It can now cope with applications which have only partially complete data such as HAL. In my testing this was sufficient to make HAL signals work.

Wed Jul 18 23:20:41 2007 dan [...] berrange.com - Status changed from 'open' to 'resolved'