Exposing the mouse battery status through HAL

[David Zeuthen]

On Tue, 2004-11-30 at 15:44 -0500, Behdad Esfahbod wrote:
> On Tue, 30 Nov 2004, David Zeuthen wrote:
> 
> > Ideally mousebatd should only be running when there is an appropriate
> > device (e.g. Logitech wireless mouse) connected to the system we should
> > monitor; for the moment it would make sense to use hal callouts (device
> > add/device remove) to activate/deactivate the daemon. I'm hoping D-BUS
> > activation on the system bus level with some clever rules will make this
> > automatic at some point, e.g. we could say 'mousebatd should run if and
> > only if a) org.fd.Hal is up; b) there is a Logitech wireless mouse.
> 
> So, is it going into the .fdi file for the mouse?  What I've been
> looking for to show up on the list was that the fdi file merge
> info saying that "run com.logitech.mouse..." daemon, and hald
> finds the callout and run it, or otherwise asks somebody to tell
> the user that she needs to install this and that package (or
> automatically dl/install?) when she plugs in stuff.
> 

Yeah, I think it makes sense to have the "the com.logitech.mouse daemon
add-on applies to this device" knowledge in .fdi files; though it should
be called org.freedesktop.Hal.Addon.input.mouse.wireless.Logitech or
something else unique; I'm not sure Logitech would appreciate you taking
com.logitech in case they one day want to ship their own addon :-)

So perhaps we should have a property called info.software.addons, should
ideally be a list (wanting to add that datatype soon), and you can merge
that long identifier above. The callout, which would be installed along
with the addon, would then check for this and activate the daemon if
it's not running.

(for now you can just declare info.software.addons to be a string and we
can sort it out when we add lists)

Ideally, distributors such as Fedora or Debian should just ship various
add-ons such as this because it's open source. Also, if I'm an OEM and
wants to ship a non-OSS add-on (it would have to adhere to the hal spec
of course), I can just ship it on the CD accompanying the device and
expect the user to install it.

If the add-on is not there some GUI could pop up in the desktop session
and tell the user that they're missing some good stuff :-) (e.g. help
them install it possibly using a distro-specific mechanism).

> About the battery stuff, perhaps Hal spec can recommend what keys
> should/may daemons set under *.battery.  For example, milliWatt
> remaining, time remaining, time to charge, charge percent, ...
> This way for example the battstat applet can simply query Hal
> tree for *.battery and show a list to the user...
> 

Yeah, I think the important thing is clearly define the nature of the
properties in the hal spec; it would be good to have some consistence as
well so the *.battery thing can be done; good idea.

Cheers,
David


_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal