disappointment over default acpid config

[Jeff Spaleta]

On 11/7/05, Richard Hughes <hughsient at gmail.com> wrote:
> I'm guessing the way to do this would be to write a *very small* daemon
> in pure C to control these devices directly. This is not what g-p-m was
> envisioned to do -- it should work on a modern GUI on top of HAL.

just to clarify for my own sake.. right now in rawhide... g-p-m is the
provided power management facility. But g-p-m needs a user to be
logged in to X before power management is active..including power
saving features for displays?

>From my own personally experience, certaintly anyone running a network
of thin clients is going to want at a minimum power saving features to
be active on the thin client moniters when no one is logged in...and
for the cpu if the thinclient allows for that.  It doesn't sound like
g-p-m provides for that right now.

There are 2 questions worth asking.
1)Should g-p-m be designed to handle the no user case or should there
different management program for the no user case? The g-p-m
developers need to answer this with authority.

2)And how the frell do you transition from one managing entity to the
other when a user does log in? Or to keep g-p-m from running if the
admin doesn't want per-user power settings and would prefer to keep
the systemwide "no user" logged in settings.


Whatever g-p-m project decides is its scope in terms of handling the
no user case... the rest of us need to be made aware..sooner rather
than later...so a second codebase can be spun up if needed.  I'd
rather see a second implimentation instead of extended  back and forth
over whether or not g-p-m should be handling these cases..getting us
nowhere.
If g-p-m has decided to punt these no user cases as a design
goal...then we need to make room for a no user solution and just as
importantly g-p-m needs to provide a facility by which another daemon
can transition control..or refuse to transition control. Don't
half-ass support for some no user cases. Either make the general no
user case part of the design or punt it completely and make room for a
transition from a no user daemon to the per-user g-p-m. Half-assing it
and only providing for "typical" no user situations is a mockery. You
might be able to claim "typical" desktop situations now..but no user
situations are going to be vastly more variable. Tying this into gdm
specifically..would be an example of a half-ass approach.
Whatever the no user solution is needs to be able to support beyond
the default dm... it needs to be a general solution.

-jef