Exposing the mouse battery status through HAL

[David Zeuthen]

On Tue, 2004-11-30 at 21:05 +0300, Andrei Yurkevich wrote:
> >I think it makes sense for hal to export this kind of information. Right
> >now hal doesn't really do as much for input devices as it could, but
> >that is another thing that I want to fix. We do export the capability
> >'input'; in the future we should export 'input.mouse', 'input.keyboard'
> >and so forth.
> >
> Perhaps in this particular case it is better to rely on some device's 
> capability of having a rechargeable battery - in this case it would be 
> possible to have a unified battery charge level/lifetime monitor for 
> different battery-powered devices in the system - think of wireless 
> mice, keyboards, PDAs, digital cameras and whatever else.
> 

I think that the direction we want take in hal is to have a number of
independent processes doing stuff; e.g. ideally all disk access (the
volume_id stuff) should be handled by a separate callout or daemon that
hald can speak with using e.g. D-BUS peer to peer. The reason for this
is security, stability and running with lower privileges than root.

(stability example: if the usb-storage kernel driver barfs, today it
puts hald into state D (uninterruptible sleep) and that effectively
halts hald; not good - if volume_id is a simple callout we can just
timeout and let that process linger on).

Btw, another reason that it might be a better to do it this way, is
because of how the code is organized; e.g. I'm now sure the battery
level on a Logitech wireless mouse is read the same way as on a PDA; I'm
quite sure it is not. Seconds, it's also easier for new open source
projects to contribute code to read e.g. the battery on a given device.

It also has the (bad or good?) side effect evil closed source vendors
may also just resort to installing a daemon to read things of the
hardware and populate hal device objects with properties defined in the
hal spec.

> >Anyway, polling for battery status on Logitech wireless mice seems like
> >a thing the hal daemon shouldn't do as it's fairly specific for a single
> >vendor. However I think it makes good sense for hal to export the
> >information as properties. As such, I think the thing to do is to create
> >a separate daemon, let's call it mousebatd to do this.
> >
> >The daemon mousebatd would use libhal to detect devices as well as
> >setting the capability input.mouse.wireless and export properties, say
> >input.mouse.wireless.battery_level on the hal device object as
> >appropriate. The battery_level property would probably be of type
> >double. Implementation-wise, mousebatd would also check usb.vendor_id
> >and usb.product_id as appropriate to only match the right devices.
> >
> >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.
> >
> Again, such a daemon could listen to device activation/deactivation 
> callouts from HAL and start/stop monitoring the devices' battery once a 
> known device is added/removed. Supporting new devices then would be just 
> a matter of adding backends/modules/whatever for that daemon that would 
> define how to read battery information from some particular device. In 
> turn, the daemon could send out messages thru D-BUS to anyone interested 
> in devices' battery status - panel applets/notifications or whatever.
> 

Yeah, well, the framework right now permits any superuser or haldaemon
user to write properties on the hal device objects so this is certainly
possible.

Cheers,
David


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