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/ _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
