I forgot to cc you guys on the future evolution of the HAL support
(it's replacement in fact, called DeviceKit)
A mailing list dedicated to DeviceKit is under creation.
If some of you are interested in, just answer back.
-- Arnaud
---------- Forwarded message ----------
From: Arnaud Quette <aquette.dev at gmail.com>
Date: 2008/6/24
Subject: Re: DeviceKit-power patches
To: Richard Hughes <hughsient at gmail.com>
Cc : David Zeuthen <david at fubar.dk>, HAL Development List
<hal at lists.freedesktop.org>
Hey Richard,
2008/6/24 Richard Hughes <hughsient at gmail.com>:> On Mon, 2008-06-23 at 16:39 +0200, Arnaud Quette wrote:
>> Hi Richard, David and the list,
>>
>> pleased to see you back on this subject, Richard ;-)
>
> Sure, thanks. :-)
sorry for lagging on the last gpm release...
have you had time to do some UPS testing (shutdown particularly)?
>> > This can make g-p-m a really small and lightweight applet, rather
than
>> > the complex thing it is today.
>>
>> I've also started to audit DK-p, and have some feedback.
>> The most important is that I find the variable naming to be unclear
>> and not suitable for expansion. For example, changing
"charge" to
>> "energy" is not a good thing.
>
> Yes, I think it's better that the HAL mapping, but it's still very
> confusing.
I don't think it's better than the HAL one (this last was mapped on
ACPI/ HID PDC, so a standard discussed by many people of the power
field). But we'll have time to discuss this ;-)
>> Moreover, before going further, I would like that we (HAL/DK-p, GPM,
>> NUT, ...) discuss the variable naming, and more generally the scope of
>> DK-p.
>>
>> For the variable naming, I would like to propose a draft,
>> merging/modifying/extending the base from the current HAL battery /
>> ac_adaptor collections and NUT variables [1].
>
> Right.
>
>> My general idea (already exposed iirc) is to promote a "Power
Module"
>> notion, composed of one or more power component (battery, input,
>
> Not input -- I think we should leave all input to INPUT and XOrg.
you've confused the human input (kbd, mouse, ...) and the input of an
UPS, ie the incoming power ;-)
so definitly not an Xorg area...
>> output, outlet, ...). This would allow a clean handling of laptop
>> batteries, UPSs, smart outlets, ... in a generic way.
>
> Sure. One thing I expose in g-p-m is the concept of physical and logical
> batteries. This could mean you have two physical batteries, but they
> work together to form one logical battery. The logical battery just has
> the average percentage of both batteries, and you can use some
> heuristics to accurately calculate the time remaining based on the
> physical battery discharge rate and the discharge profile of the laptop.
yup, that's also a notion I've developed (and called "meta
device", or
"composite device").
the thing is that for an UPS, you can have various topologies (serial
or paralell) which gives different "meta" results.
>> There is also a notion of power chain (imagine a UPS powering a smart
>> strip, with some boxes and peripherals ; managed smartly, like
>> powering on a printer on demand...), with a Power Module hierarchy...
>
> Hmm, I'm not sure that's in scope -- I'm not sure DavidZ wanted
a tree
> to populate and navigate. Correct me if I'm wrong.
it really *must* be in the scope, or we'll end up with something
simple that won't address the power management needs in general, but
only the basic ones!
for the tree notion, this is far the best approach to manage the
various devices and topologies.
but once more, we'll discuss this on the new ml.
>> So, David, same question: is it the right place to talk about that?
>
> We'll discuss on the new list :-)
sure
cheers,
Arnaud
--
Linux / Unix Expert R&D - MGE Office Protection Systems -
http://www.mgeops.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/