org.freedesktop.PowerManagement

[Lubos Lunak]

On pá 30. března 2007, Brian J. Tarricone wrote:
> On Fri, 30 Mar 2007 23:19:26 +0200 Lubos Lunak wrote:
> > I thought supporting an opinion did not require one to repeat it, but
> > if you
> >want: Shutdown/Reboot are basic functionality but power management
> >features are an add-on that not everybody may be interested in having
> >(see above for my feedback on that part). Since a DBUS interface
> >cannot be split that makes the whole org.fd.PM interface optional and
> >therefore Shutdown/Reboot should not be part of it.
>
> There's nothing stopping someone from implementing a daemon that
> handles org.fd.PM and only supports the Shutdown/Reboot methods.  For
> the CanStandby/CanSuspend/CanHibernate methods, just return FALSE.  For
> the Standby/Suspend/Hibernate methods, return the NoHardwareSupport
> error.  For GetPowerSaveStatus and GetBatteryState, return FALSE.  If
> other methods are added, I'm sure dummy non-implementations can be
> added for people who really care about saving 200k of RAM.

 Or, since the two things are[*] independent, they can have independent 
interfaces and supporting either only one of them or both of them is simple. 
No dummies needed.

[*] Unless you have another reason why shutdown/reboot should go together with 
PM besides the Inhibit functionality, which for shutdown/reboot exists in the 
form of session management.

 (In fact, thinking of it right now, perhaps even having Inhibit in PM 
interface is not quite right? A DVD burner app strictly speaking probably 
doesn't care about the machine being suspended, it just wants to keep the DVD 
device until it's finished and the machine shouldn't shutdown with the DVD 
device being busy - so in fact maybe it should be HAL preventing suspend in 
such case. You can have Inhibit for the screen, which is a bit like keeping 
the screen, but that has nothing to do with shutdown/reboot again. But maybe 
this is overengineering it already and irrelevant to the 'should 
shutdown/reboot be part of PM' topic anyway.)

> At any rate, you're complaining about a specific implementation being a
> memory hog.  Take your beef to the authors of that software.  The
> org.fd.PM interface is mostly orthogonal.
>
> Of course, the ridiculously ornery among us can just open a terminal
> and type 'sudo poweroff'; they won't even run g-p-m or kpowersave or
> whatever, and any apps they run won't be able to make use of the
> advanced features org.fd.PM can offer.  Your average user who would
> benefit from org.fd.PM features won't care about a meg or two of RAM
> gone missing.

 This is not about g-p-m being a memory hog or not, this is about the 
principle. Everything has its cost and you want to make a power management 
daemon compulsory even just for shutdown. Okay. Next week somebody proposes a 
WIFI access daemon should be made compulsory for some reason, because, after 
all, your average user will benefit from it and who cares about a meg or two. 
Actually two or four, by now, things add up. Do I need to continue to the 
next month and later and add up more? I'd prefer not to, I feel strongly 
tempted to point out some flamewar material. Let's just say that there are 
users who also care about this, ok?

 Besides, the main reason is that having shutdown/reboot seen as a part of 
power management functionality simply seems technically wrong.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz