GNOME Bugzilla – Bug 585955
Shouldn't we move from hal to DeviceKit?
Last modified: 2020-06-06 16:31:01 UTC
According to :
hal is more or less dying. We shouldn't be too hurt by the change, since that part if engine-ified already...
It seems we are late:
" June 13
GNOME 2.27.3 unstable tarballs due
Complete migration from HAL to DeviceKit-* done."
I've seen some messages about this migration, people asking about x or y software.
Maybe the issue with jhbuild not being able to build Ekiga is responsible for the lack of attention...
(In reply to comment #1)
> It seems we are late:
> " June 13
> GNOME 2.27.3 unstable tarballs due
> Complete migration from HAL to DeviceKit-* done."
Ah well. My release schedules are challenging, but Ekiga is not the only app still using HAL. In the end I just want GNOME 3 to be clean, that's all. :-)
A ping here to remind us this must be fixed for next Gnome. AFAIK Ubuntu already dropped HAL for its next release (due in april 2010)...
Behind this, my question is: new 3.2.x or 3.4 for patching to remove HAL dep? Guys ?
Maybe a rise in priority would be nice too...
Should we shoot for the DBUS interface or for the gobject-based lib?
Through the DBUS interface would be better because :
- it wouldn't mean a binary dependency ;
- it's probably easier to port from our hal-dbus code (not sure) ;
and the gobject-based lib would be better because :
- as it's header-based, the code will stop compiling when the interface changes.
(In reply to comment #4)
> gobject-based lib?
I assume you refer to the new gdbus in gio and not the old dbus-glib?
To be more specific, I meant :
- for the DBUS interface : http://hal.freedesktop.org/docs/DeviceKit/DeviceKit.html
- for the gobject-based lib : http://hal.freedesktop.org/docs/DeviceKit/ref-gobject.html
Isn't it what should be used?
Reopening as I can't see any open non-developer question.
For info: gnome 3.0 has recently been pushed to Spring 2011, the next gnome release (in September) being 2.32.
Is there some place where more is said about how to migrate?
I have no clue what HAL's 'category' "alsa" and 'type' "capture" has become, and don't know exactly how to know about a removal/addition... is that was DeviceKit names an 'action' in the DeviceEvent signal?
Porting ekiga should be straightforward with adequate documentation ; here is what ekiga wants :
- enumerate devices (network interfaces, audio input, audio output, video input) [EnumerateBySubsystem probably does what we want] ;
- listen to a signal to know when a device gets added or removed [DeviceEvent is probably what we want].
(In reply to comment #9)
> Is there some place where more is said about how to migrate?
> I have no clue what HAL's 'category' "alsa" and 'type' "capture" has become
Probably ask David Zeuthen?
DeviceKit is obsolete as it was easier to provide this in library form instead of a D-Bus service. So that functionality is now in libgudev and has been for a while.. more than a year actualy.. and it's in all the main distros and so on. See
Btw, I really don't think you want to mess around with ALSA devices - you probably just want to use PulseAudio instead.
You may still want to use libgudev for webcams - maybe do whatever Cheese is doing? That seems to work fine and I remember collaborating with the Cheese developers on getting some udev rules sorted.
Ekiga is not under active development anymore:
Ekiga saw its last release 7 years ago. The last code commits were 4 years ago.
Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (and transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active Ekiga development again in the future.