Exposing the mouse battery status through HAL

[David Zeuthen]

On Tue, 2004-11-30 at 21:36 -0500, David Zeuthen wrote:
> 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 :-)
> 

Thinking a bit more about it perhaps the property should be called
info.software.addons.input.mouse.wireless and we should merge
"org.freedesktop.Hal" in the .fdi file because we are the vendor of that
addon (e.g. it's in the hal tarball). In some theoretical future
Logitech could override that property with "com.logitech", with .fdi
files of their own, and make their own polling daemon run instead of
ours [1].

Cheers,
David

[1] : Not that I think that is likely, but I like a clean extensible
architecture. This could also extend to what open source kernel driver
(using info.software.kernel_driver), e.g. usb-storage or ub, to choose
once we get driver binding working from user space (which, according to
Adam Belay, may happen sooner than later).


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