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. 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
