disappointment over default acpid config

[Richard Hughes]

On Mon, 2005-11-07 at 09:39 -0500, Jeff Spaleta wrote:
> 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.

It is one "option" :-)

>  But g-p-m needs a user to be
> logged in to X before power management is active..including power
> saving features for displays?

I don't know about displays. g-p-m just sets the timeout value for
gnome-screensaver, so it doesn't really get involved with the details.
Does gnome-screensaver run at the login screen?

> >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.

Ohh, I agree. I'm not sure how the screenblanking is handled at the
login screen... anyone?

> 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.

Well, I guess I'm the main developer -- but I need more information to
answer this question fully. Can we run an arbitrary program (little
daemon) at gdmlogin time? In that case I could produce a "little-g-p-m"
daemon that has no gui but does the same stuff, which quits as soon as a
session g-p-m takes over. I think dbus connection management could be
used quite cleverly here too.

> 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.

g-p-m just uses dbus permissions to talk to HAL, so the admin can
certainly lock this down per user, or per group. By default, anyone
"at_console" can do any "powersaving" action.

> 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.

Agreed. I'll have a bit of a hack this afternoon and see how quickly I
can knock up a said daemon.

> 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.

Oops. Why half-assed?

> Whatever the no user solution is needs to be able to support beyond
> the default dm... it needs to be a general solution.

What about an optional system initscript that just runs this mini-g-p-m,
and then once the session g-p-m kicks in, it unloads? The whole system
initscript things gets very messy, very fast. I've tried this in the
past (early in the g-p-m archives) and it was horrid.

Richard.