hal and battery status

[Nathaniel McCallum]

On Tue, 2004-07-06 at 20:43 +0200, David Zeuthen wrote:
> On Mon, 2004-07-05 at 22:54, Nathaniel McCallum wrote:
> > Well, I'm not very knowledgeable about apm or pmud (apples power
> > management).  However, we are generally dealing with several types of
> > data:
> > 	1. Hardware attributes (non-changing, ie. battery size)
> > 	2. State attributes (changing, ie. current battery charge)
> 
> Right. On a HalDevice (see hald/hal_device.h) this corresponds to
> properties, these are typed. Whenever they are updated, notifications
> are broadcast on the system message bus.
> 
> > 	3. Events
> > 
> 
> This corresponds to DeviceConditions in HAL. We already do this for
> announcing that a block device have been unmounted.

So basically, we'll use /proc/acpi/... for #1, poll /proc/acpi/... for
#2 and use #3 (/proc/acpi/events) to update the HalDevice properties?

How should power/sleep buttons be handled?  The don't have any
properties, only events...

> > All this stuff is available in /proc/acpi/... I have no idea what will
> > be available in sysfs in the future, if ever.
> > 
> 
> Good question.

I grepped the lkml, but didn't really find anything.

> > Regarding the splitting up of devices (power button, lid, etc).  I don't
> > think there is any info for several of those devices (other than
> > events).  ie. for the types of data listed above, power buttons, lids,
> > etc have only events.  So I'm not sure how exactly we would profile it. 
> 
> Isn't this in /proc/acpi, in [1] is how it looks like on my Dell
> Inspiron 7500. So I guess lid, power and sleep in /proc/acpi/button is
> what we are after; we create one HalDevice for each of them.

I was just thinking that mostly apci for those devices is just events.
I was more just thinking outloud.

> > What about profiling acpi as the device? (and apm and pmud as seperate
> > devices).  
> 
> This I think is a bad idea - we really want to abstract this into
> concepts (e.g. buttons, batteries, CPU's that is in every box) that can
> be mapped to the architecture in use.

Again here, thinking outloud.  You are right, profile the individual
devices.

> 
> > Other than that, I like your division:  Power, standby and
> > lid etc buttons, battery bays, and cpu.
> > 
> > I'm really not familiar with how hal works internally, but I can learn.
> > 
> 
> Nice - it should be pretty easy. Just create a HalDevice, populate it
> with some propoerties and then add it to the GDL (Global Device List)
> and then it should be visible in hal-device-manager.

My sister is over-due on her baby, so this week is a bit busy.  However,
I'll try to start on this asap.

> I've got a Powerbook, so I'm happy to do the Apple parts.

Cool.

Nathaniel


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