G-P-M on the wrong track?!

[Danny Kukawka]

On Sunday 16 October 2005 18:04, Matthias Grimm wrote:
[...]
> > Also putting all the ACPI data in HAL has let us fix *many* broken
> > BIOS's, so that any userspace application doesn't have to care about
> > the specific details. I know its not such an issue for the PMU laptops
> > out there, but ACPI is broken more of the time than working.
>
> Is this the way to go? The kernel has already an ACPI interface in /proc
> and can handle broken BIOSs much better than HAL can. Repairing of
> broken BIOSs is not the task of HAL.

IMO you are right. This is a task for kernel, hardware producer (to fix bios) 
or/and a special powermanagment daemon.

> I think a better solution would be, and I'm quite sure you meant it
> that way, to define schemas for certain elements (like batteries) in HAL
> and fill the data (level, max charge, etc. Whatever is nedded to show
> useful data in a battery monitor on the desktop) nevertheless where the
> data come from (ACPI, APM, PMU or any daemon).

right, you can also fill information for broken bios in HAL with/from a other 
(powermanagement) damon. 

> > What's the point? That limits hal to being a flashy version of lspci
> > and lsusb when it has *so much more* potential.
>
> Partly yes partly no. HAL shouldn't mirror /proc and /sys but provide
> filtered information for desktop applications.
>
> > David Zeuthen (HAL maintainer) seemed happy with my changes, and I've
> > got no reason to think that he's not okay with the direction HAL has
> > taken. (David, speak up if you have!)
>
> This is not a matter of "making someone happy". I would be happy too,
> if you sent so many patches for pbbuttonsd to me :-)
>
> HAL is going to become an essential part of GNU/Linux desktop systems
> and therefore is must reach an stable state very soon. Application
> programmer must be able to rely on its API and feature set. More
> important than adding new features would be to define the data scheme
> for certain elements so that daemon programmer could fill and desktop
> application programmers could use them.

Yes, we need a more actual and stable API for HAL. We should discuss more 
about this issue and we need to update the specification which is currently 
in many parts out of date and not in sync with the code.

[...]

Cheers,

Danny