G-P-M on the wrong track?!

[Danny Kukawka]

On Sunday 16 October 2005 18:02, Matthias Grimm wrote:
[...]
> You already split up g-p-m in two parts. One part becomes
> the desktop part and everything else, you can't do without root
> permissions, you graft on HAL. I thinks that is not very fair ;-) You
> have still a daemon and a desktop application. Think about it.

Same for me, this is the concept with powersave/kpowersave ;-)

[...]
> This approach reaches to short. your design expects that a user is
> logged  in in X11, running gnome and gnome-screensaver to stick with
> your example above. But you can't expect all people to work this way.
>
> For instance I never use a screensaver. Nevertheless would g-p-m get
> the idle information? 

IMO you could get this information with little code from X11 server.

> Other users remotely log into their laptop and 
> expect that the power management will recognise this and allow working
> even with closed lid. There are thousand methods people will use their
> computer and the powermanagement must support them all.

see powersave ;-) , you need also a solution if nobody is logged in. For 
example: what happens if nobody is logged in and the battery gets empty? If 
you have a daemon: shutdown or suspend if a defined battery fill will 
reached.

> And beside the simple suspend-to-ram example the daemon must handle much
> more complex tasks such as controlling the LCD brightness depending on
> an ambient light sensor, which raw signal is influenced by current the
> LCD brightness and must be compensated before usage. Those and much more
> tasks have to be implemented in HAL. Do you really think this makes
> sense? Wouldn't it be better to put those functions in an seperate power
> management daemon?

agree

[...]
> > HAL does that job now. In KDE4 HAL plays a more prominent role.
>
> Yes, I'm sure. But they also need the policy agent like g-p-m, for the
> intelligence, don't they? They could use an independent power management
> daemon without change but this is more the matter of distributors than
> of desktop systems. The KDE people always have to implement the
> configuration stuff themselves because of the Desktop Look&Feel but
> don't have to care about policies and methods.

agree

[...]

Cheers,

Danny