On Mon, 2005-11-07 at 09:39 -0500, Jeff Spaleta wrote: > On 11/7/05, Richard Hughes <hughsient@xxxxxxxxx> 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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
