[systemd-devel] logind lid default configuration feedback

[Colin Guthrie]

Hi,

'Twas brillig, and Jiří Procházka at 03/10/12 02:50 did gyre and gimble:
> Greetings,
> I'm here to complain about a bad decision to default configuration keys
> HandleLidSwitch to suspend (instead of ignore) and
> LidSwitchIgnoreInhibited to yes (instead of no).

This isn't really possible without putting a lot more "high level" logic
in systemd. Consider when there is no DE running and the machine is just
sitting at a getty prompt. The user closes the lid and puts their laptop
in their backpack and goes off-roading in a jeep. They user is suprised
their hard drive is trashed because the laptop was not suspended because
the default was off/ignore.

> Many of users use desktop environments handle this action and its
> configuration (like XFCE in my case).

Many users do, and in this case if the DE wants to handle power, they
should make the necessary minor tweaks to take out their own inhibitors
such that logind will behave as they expect.

systemd and logind provide the building blocks, and the various
permutations and use cases were discussed here. If you look at the
archives you'll see why your suggestion wouldn't work for various use cases.

> Aside of rather obvious point of
> overlap of responsibilities, which is a problem rather diplomatical and
> hard to solve - not point of my call, the problem I have is that
> Systemd's Logind makes a certain assumption about user wants and forces
> it down on them. 

No, logind specifies some defaults that, logically, cannot really be
specified any other way. If the DE's want that to override this, then
they will have to make a couple tweaks to do so, but it's certainly not
impossible.

> Not everyone wants their laptop to suspend to RAM when
> the lid is close.

Fully agree, that's why there are mechanisms to disable this behaviour,
especially on multi-monitor systems. Patches already exists for Gnome
which make this work, similar changes will be needed in other DEs.

> After an update of my system (which in this case
> brought logind on) I expected my system to work at least like it worked
> before (if not better), respecting my configuration choices, I closed my
> laptop lid and walked away for an hour or so, I expected it to crunch
> data, I lost that time due to bad logind default config decision,
> fortunately not that a big deal, but the principle holds. I hope any new
> software developments will have more of that respect.

Well your system was updated without a holistic view of what the changes
would bring. While I agree that an overall "status quo" in behaviour is
desirable, sometimes the cannot be guaranteed when updating one
component at a time.

You can rest assured that at a higher level, there is broad agreement
with what you say, but you cannot always maintain that when upgrading
individual components - changes often have to be co-ordinated for this
to work smoothly.

So please try not to be too upset or angry about "poor defaults". There
is good reason for these decisions. You just need to make sure the other
components are updated to fall in line with these changes such that your
overall experience is unaffected.



Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/