G-P-M on the wrong track?!
danny.kukawka at web.de
Mon Oct 17 04:38:54 PDT 2005
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
> 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?
> > 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.
More information about the hal