Exposing the mouse battery status through HAL

[David Zeuthen]

On Thu, 2004-12-02 at 00:14 +0000, Sergey Udaltsov wrote:
> So, as I promised, here is the list of the properties I propose for
> the capability "rechargeable":
> 

Awesome - this looks really good. Comments inline.

How about just calling it 'battery_level' instead of 'rechargeable' so
we can deal with devices that has batteries that are not rechargeable? I
guess this applies to some wireless mice (certainly true for my
bluetooth wireless mouse).

> - "rechargeable.type" (string, mandatory) - "laptop", "mouse", "PDA",
                                              ^^^^^^^^

Laptops can have zero or more batteries; I envision that when we get
down to dealing with ACPI and PMU we'll add separate hal device objects
for each battery that is inserted (adding and removing as appropriate).
Such device objects should probably have capability 'battery' (thus why
I want to call rechargeable for battery_level).

> "UPS", "keyboard", "cellphone", "photocamera", "toy", "other" - some
> set of well-known values (to be extended). This will help indicators
> to find the appopriate icons. 

Neat.

> Usually taken straight from fdi.
> 

Yeah, I think the process (mousebatd or whatever) would probably set
this as it knows exactly what kind of device it is? 

My point is that the fewer things we need to merge from .fdi files the
better, cause that makes it simpler to add support for new devices (e.g.
by matching on usb_vendor_id, usb_product_id). Also, we only want to set
this when we are actually monitoring the device.

Also, this is somewhat redundant because e.g. you merge the
battery_level.* properties on a device with known hal capabilities
anyway (e.g. input.mouse, battery, ups). But I think it is still nice to
have this level of redundancy because that makes it easier to write
graphical desktop battery applets.

> - "rechargeable.charge_unit" (string, mandatory) - the unit name.
> possible values: "milliWatts", "VA", ... Can be just "" - it means
> some relative "units". Usually taken straight from fdi.
> 

Should also come from daemon, not fdi

> - "rechargeable.maximum_battery_level" (int, mandatory) - the maximum
> level of the battery charge, in "units". Usually taken straight from
> fdi.
> 

Should also come from daemon, not fdi

> - "rechargeable.current_battery_level" (int, mandatory) - the current
> level of the battery charge, in "units". Handled by the
> callout/daemon/...
> 

Yup.

> - "rechargeable.is_charging" (bool, mandatory) - whether the device is
> charging or not, handled by the daemon. If this property is "true" and
> "current_battery_level" = "maximum_battery_level" - it means that
> device is simply working from AC (being fully charged). Handled by the
> callout/daemon.
> 

Looks good - might want to introduce bool battery_level.is_rechargeable
as a mandatory bool and battery_level.rechargeable.is_charging as
mandatory if, and only if, battery_level.is_rechargeable==TRUE. That's
the pattern we use for use properties in hal.

> Note: In theory, the property "rechargeable.is_plugged_in" can be
> introduced - but I'd consider it as redundant. Or it can be made
> optional.
> 

I would call it battery_level.rechargeable.is_recharging and make it
mandatory if and only if battery_level.is_rechargeable==TRUE.

> - "rechargeable.command_interface" (string, mandatory?) - helps
> callouts to find the devices it can handle. Usually taken from fdi.
> For logitech mice, this is going to be
> 

This should be taken from the .fdi files yeah; I think it would make
sense to call it

 info.software.addons.input.mouse.battery_level

and merge org.freedesktop.Hal.Software.Addons.LogitechMice to that
property. This would mean that the daemon shipped with the hal package
for monitoring battery level on mice should be used. This can be
overridden by 3rd party packages and OEM's by them setting it to e.g.
com.logitech.Hal.Software.Addons.Mice.OurClosedSourceSoftwareRevision42.

Just a thought.

> - "rechargeable.time_to_charge" (int, optional, in minutes) - if some
> predictions can be made by the callout/daemon, they are here. This
> property can be defined even when "is_charging" is false. (though they
> always recommend to discharge batteries fully before charging).
> Handled by callout/daemon.
> 

battery_level.rechargeable.time_to_charge - optional, yeah.

> - "rechargeable.time_to_discharge" (int, optional, in minutes) - if
> some predictions can be made by the callout/daemon, they are here.
> This property can be defined even when "is_charging" is true (though
> they always recommend to charge batteries fully before discharging)
> Handled by callout/daemon
> 

battery_level.rechargeable.time_to_discharge - optional, yeah.

Looks very good - hope my minor nitpicking is OK.

Cheers,
David

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