org.freedesktop.PowerManagement

[Brian J. Tarricone]

On Sat, 31 Mar 2007 00:34:32 +0200 Lubos Lunak wrote:

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

My thought was that the general feeling here is that XSMP is crufty,
broken, and not extensible, so we shouldn't rely on it for this kind of
functionality.  (Personally, I hope XSMP goes away entirely in favor of
some as-yet-defined new method of managing sessions that doesn't suck.)

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

What's wrong with that?  As I said, this "power management daemon" can
simply implement shutdown and reboot, and nothing else.  Perhaps the
use of the phrase "dummy implementations" was foolish: a stub that just
says "we don't support this part of the interface" seems eminently
reasonable to me, and reduces interface count and complexity of the
platform as a whole.

> 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

Well, yes.  If you have a wireless card, you'll probably want an easy
interface for turning it on and off.  While a daemon may or may not be
necessary, you'll likely have to run *something* to control it
(wpa_supplicant running as a daemon comes to mind).

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

And I submit that they are wrong to worry about it to that level.
Adding useless functionality that increases memory usage is bloat.
Certainly.  Adding useful features to integrate the desktop (in a
per-module opt-out manner, ideally) is a good thing.  Memory usage
should not be an issue, and any decent programmer can write a daemon
implementation that is memory-efficient.

And yes, it all does add up.  But: if you don't have a wireless card,
you don't run the wireless daemon.  If you don't have a printer, you
don't run the printer daemon.  If you don't care about
suspend/hibernate/power saving, you don't run a PM daemon that
implements those.

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

I guess we just disagree on this: it seems technically correct to me.
I could maybe see merit in the idea that 'reboot' is a different
animal, but in my eyes, suspend, hibernate, and shutdown all go
together and are all about power management (the only difference being
that shutdown trashes your state).  And having a separate interface for
one single operation -- reboot -- is silly IMHO.

	-brian