During the 2.25 release cycle I would like to move GNOME Power Manager away from a HAL dependency and onto a new DeviceKit-power dependency.
DeviceKit-power is a new mechanism daemon that moves the battery profiling and statistics interface system-wide, and also does the history recording once per system, rather than once per session. It also moves to an interface that is legacy-free and is more focused on the entire power management system than HAL ever was. You can see some screenshots of the new functionality on my blog: http://blogs.gnome.org/hughsie/2008/11/09/gnome-power-manager-and-devicekit-power/ -- At the moment you have to compile with --enable-devicekit to get the new functionality. Q: Why is system wide better? A: There's no point doing the data collection, statistics profiling and calculations in every session on a multiuser workstation. There's also the point that at GDM you run a g-p-m instance, which doesn't have access to the profiling data you generate in the session, and so you get "unknown time remaining". Q: What's wrong with HAL? A: HAL has grown into a mega-daemon doing a little bit of everything, it evolved with DBUS over a number of years and is now pretty horrible code. The DeviceKit set of daemons replace core functionality of HAL and are developed by the very same maintainers as HAL was. HAL also has a very low level interface, and so apps needed tons of complicated code in the session to do simple things like work out remaining battery lifetime. Q: Is anything else going to use DeviceKit-$foo? A: In the future gvfs will depend on DeviceKit-disks, not HAL Q: Yet another system daemon?!? A: No, all the DeviceKit daemons are system activated and low footprint, so if you don't need them they don't get started. Q: Can't you have --enable-hal and enable-devicekit in configure? A: Not without a thousand #ifdefs, we would essentially have two seporate engines which I don't want to support. I'm was trying to do that on trunk and it's was getting crazy. DeviceKit-power also implements a QoS (Quality of Service) interface for latency control, and in the future will be used for _aggressive_ application power control. This is needed to produce a desktop that uses little power when idle, but doesn't feel sluggish. There's more information about this on my blog too. What I propose is to switch trunk to using DeviceKit-power, and if distros don't want to ship the very new code in 2.26.0, they can stick with the old HAL only code of 2.24.x, like some distros last cycle did with GDM. Of course, I'll still continue to actively maintain the 2.24 in parallel with the new development. Switching to DeviceKit-power allows me to make g-p-m the simple session process it should be, rather than the mess of legacy and complex code it is now. DeviceKit-power and DeviceKit-disks just depend on the trivial DeviceKit daemon which is a thin dbus wrapper around udev. So, comments please. Richard. _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
