[opensuse-factory] systemd version 210 Heads Up
Hi List Mates, Just a very early warning with regards to the latest released systemd version (version 210). In the release notes the following two items will have an effect on people that are utilizing laptops with a docking station and an external monitor. * logind is now a lot more aggressive when suspending the machine due to a closed laptop lid. Instead of acting only on the lid close action it will continuously watch the lid status and act on it. This is useful for laptops where the power button is on the outside of the chassis so that it can be reached without opening the lid (such as the Lenovo Yoga). On those machines logind will now immediately re-suspend the machine if the power button has been accidentally pressed while the laptop was suspended and in a backpack or similar. * logind will now watch SW_DOCK switches and inhibit reaction to the lid switch if it is pressed. This means that logind will not suspend the machine anymore if the lid is closed and the systemd is docked, if the laptop supports SW_DOCK notifications via the input layer. Note that ACPI docking stations do not generate this currently. Also note that this logic is usually not fully sufficient and Desktop Environments should take a lid switch inhibitor lock when an external display is connected, as systemd will not watch this on its own. The first item concerns a change that systemd is monitoring if the lid is closed or not. This monitoring starts already during the system boot process which would lead to the effect that the system is forced into suspend mode even before the login manager is reached. To prevent this, the second item was implemented, however as indicated current kernels (including the latest 3.14- rc4) do not support this yet for all laptops. The issue however is that the system will not reach the Desktop Environment yet as that this new principle already kicks in during the boot process. So implementing a lid switch inhibitor in GNOME/KDE/etc does not make any sense as that the system will never reach the desktop environment. I had a couple of email conversations with Lennart about this topic yesterday and finally with my last message he got the real issue that this happens during system boot and therefore systemd should handle this properly. He indicated that he will resolve the issue in one of the upcoming versions of systemd and also probably move the external monitor detection out of the DEs into logind. (The situation will then be that if the lid is closed and an external monitor is connected, then systemd will not suspend the system). If the decision is taken by the systemd maintainers, then in my opinion it would be good to revert the two commits in systemd version 210 that implement the two items mentioned so that the old lid switch behavior is restored. Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Tue, 25 Feb 2014 09:51:15 +0100, Raymond Wooninck wrote:
Hi List Mates,
Just a very early warning with regards to the latest released systemd version (version 210). In the release notes the following two items will have an effect on people that are utilizing laptops with a docking station and an external monitor.
* logind is now a lot more aggressive when suspending the machine due to a closed laptop lid. Instead of acting only on the lid close action it will continuously watch the lid status and act on it. This is useful for laptops where the power button is on the outside of the chassis so that it can be reached without opening the lid (such as the Lenovo Yoga). On those machines logind will now immediately re-suspend the machine if the power button has been accidentally pressed while the laptop was suspended and in a backpack or similar.
* logind will now watch SW_DOCK switches and inhibit reaction to the lid switch if it is pressed. This means that logind will not suspend the machine anymore if the lid is closed and the systemd is docked, if the laptop supports SW_DOCK notifications via the input layer. Note that ACPI docking stations do not generate this currently. Also note that this logic is usually not fully sufficient and Desktop Environments should take a lid switch inhibitor lock when an external display is connected, as systemd will not watch this on its own.
The first item concerns a change that systemd is monitoring if the lid is closed or not. This monitoring starts already during the system boot process which would lead to the effect that the system is forced into suspend mode even before the login manager is reached. To prevent this, the second item was implemented, however as indicated current kernels (including the latest 3.14- rc4) do not support this yet for all laptops. The issue however is that the system will not reach the Desktop Environment yet as that this new principle already kicks in during the boot process. So implementing a lid switch inhibitor in GNOME/KDE/etc does not make any sense as that the system will never reach the desktop environment.
I had a couple of email conversations with Lennart about this topic yesterday and finally with my last message he got the real issue that this happens during system boot and therefore systemd should handle this properly. He indicated that he will resolve the issue in one of the upcoming versions of systemd and also probably move the external monitor detection out of the DEs into logind. (The situation will then be that if the lid is closed and an external monitor is connected, then systemd will not suspend the system).
If the decision is taken by the systemd maintainers, then in my opinion it would be good to revert the two commits in systemd version 210 that implement the two items mentioned so that the old lid switch behavior is restored.
What happens if a machine is booted with the lid closed (e.g. via WoL or a timer)? Will the machine go again to suspend immediately? The integrating the external monitor detection into logind doesn't look like a good solution to me. The external monitor detection isn't guaranteed to work always, even if the lid switch detection works. For example, you can delay the loading of KMS module (e.g. nomodeset due to driver breakage). Then the external monitor can't be detected. Meanwhile, the lid switch is reported by the input driver, so logind will catch it and tries to suspend. I hope we won't fall into such a stupid scenario... Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 25 February 2014 18:19:28 Takashi Iwai wrote:
What happens if a machine is booted with the lid closed (e.g. via WoL or a timer)? Will the machine go again to suspend immediately?
If the lid is closed and the machine is not docked (or docking is not detected), then yes the machine is directly suspended again. As indicated yesterday morning I had this issue while trying to boot the system. Before I realized what exactly was happening, the system suspended already around 4 times. Only opening the lid "resolved" it and the system booted normally. So yes, in the future if there is no external monitor connected then the system will directly go into suspend state again as that the lid is closed. As Lennart describes it as an accidental power-on of the system.
The integrating the external monitor detection into logind doesn't look like a good solution to me. The external monitor detection isn't guaranteed to work always, even if the lid switch detection works. For example, you can delay the loading of KMS module (e.g. nomodeset due to driver breakage). Then the external monitor can't be detected. Meanwhile, the lid switch is reported by the input driver, so logind will catch it and tries to suspend. I hope we won't fall into such a stupid scenario...
Lennart indicated that he would start working on a solution after release of version 210. This is the direction that he indicated and I guess that more knowledgeable persons than me in this area could try to talk to him in finding the right solution. Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Tue, 25 Feb 2014 18:30:47 +0100, Raymond Wooninck wrote:
On Tuesday 25 February 2014 18:19:28 Takashi Iwai wrote:
What happens if a machine is booted with the lid closed (e.g. via WoL or a timer)? Will the machine go again to suspend immediately?
If the lid is closed and the machine is not docked (or docking is not detected), then yes the machine is directly suspended again. As indicated yesterday morning I had this issue while trying to boot the system. Before I realized what exactly was happening, the system suspended already around 4 times. Only opening the lid "resolved" it and the system booted normally. So yes, in the future if there is no external monitor connected then the system will directly go into suspend state again as that the lid is closed. As Lennart describes it as an accidental power-on of the system.
That's a very wrong assumption. An obvious counter case is to use a laptop as a server.
The integrating the external monitor detection into logind doesn't look like a good solution to me. The external monitor detection isn't guaranteed to work always, even if the lid switch detection works. For example, you can delay the loading of KMS module (e.g. nomodeset due to driver breakage). Then the external monitor can't be detected. Meanwhile, the lid switch is reported by the input driver, so logind will catch it and tries to suspend. I hope we won't fall into such a stupid scenario...
Lennart indicated that he would start working on a solution after release of version 210. This is the direction that he indicated and I guess that more knowledgeable persons than me in this area could try to talk to him in finding the right solution.
Grr... I'm looking forward to seeing the next Debian TC :) Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2014-02-25 18:45, Takashi Iwai wrote:
On Tuesday 25 February 2014 18:19:28 Takashi Iwai wrote:
What happens if a machine is booted with the lid closed (e.g. via WoL or a timer)? Will the machine go again to suspend immediately?
If the lid is closed and the machine is not docked (or docking is not detected), then yes the machine is directly suspended again.[...]
That's a very wrong assumption. An obvious counter case is to use a laptop as a server.
It may be a counter case, but not a very _common_ case. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Tue, 25 Feb 2014 18:49:45 +0100 (CET), Jan Engelhardt wrote:
On Tuesday 2014-02-25 18:45, Takashi Iwai wrote:
On Tuesday 25 February 2014 18:19:28 Takashi Iwai wrote:
What happens if a machine is booted with the lid closed (e.g. via WoL or a timer)? Will the machine go again to suspend immediately?
If the lid is closed and the machine is not docked (or docking is not detected), then yes the machine is directly suspended again.[...]
That's a very wrong assumption. An obvious counter case is to use a laptop as a server.
It may be a counter case, but not a very _common_ case.
It doesn't matter at all how common it is. We can't enforce such policy (preventing login for the known working cases) to a fundamental service like logind. For example, we may enhance logind to allow login for only limited letters. It'd speed up the boot time in 2ns. Wonderful! Unfortunately, a user id like jengelh can't login properly any longer, but such an id isn't very common, so no big problem. OK, OK, we should provide an easy workaround in addition. You can disable this limit easily by putting $HOME/.let_me_in file. It's trivial, isn't it? :) Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2014-02-25 21:09, Takashi Iwai wrote:
For example, we may enhance logind to allow login for only limited letters. It'd speed up the boot time in 2ns.
That does not have any relation to suspend, nor using laptops as servers. Surely you want sysvinit too? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Tue, 25 Feb 2014 22:19:43 +0100 (CET), Jan Engelhardt wrote:
On Tuesday 2014-02-25 21:09, Takashi Iwai wrote:
For example, we may enhance logind to allow login for only limited letters. It'd speed up the boot time in 2ns.
That does not have any relation to suspend, nor using laptops as servers.
Sigh, there is nothing more foolish than explaining a joke in details... The point is that, in both cases, you'll get the same result: cannot login on system any longer. With the lid-closed-at-boot case, the system doesn't boot properly because it suspends immediately. With a change I gave as an example will prevent the login for certain users, too. When you read further my text: "Unfortunately, a user id like jengelh can't login properly any longer, but such an id isn't very common, so no big problem." The next point is that you tried to justify this problem just because it's a minority (not _very_ common). If this logic can be accepted, you should accept a change like what I suggested (e.g. limit the login without "j" start letter, which must be not _very_ common). And, yet, further reading: "OK, OK, we should provide an easy workaround in addition. You can disable this limit easily by putting $HOME/.let_me_in file. It's trivial, isn't it? :)" This indicates that the opt-out doesn't work always. Even if you have a way to disable it, how would you perform it when you cannot login? Even with a boot option, it's not always possible. Some EFI loader may not allow you to edit the boot option. And this may happen by just updating a package. At the next boot, you'll be unable to login at all out of sudden. So, to repeat myself: - A fundamental service like logind must cover all use cases, no matter how major / minor it is. - The default policy enforcement must be chosen very carefully. Is the assumption really correct? ("booting with the closed lid must be accidental", "login id mustn't start with j".) - The opt-out doesn't work always, thus it cannot be always an excuse of problems.
Surely you want sysvinit too?
Oh, don't start that useless thread again... And, it's not about init. It's about logind. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 26/02/14 03:30, Takashi Iwai escribió:
So, to repeat myself: - A fundamental service like logind must cover all use cases, no matter how major / minor it is.
I disagree, It is my belief (and I think upstream's as well) that logind should only support a set of most common use-cases only. not everything.
- The default policy enforcement must be chosen very carefully. Is the assumption really correct? ("booting with the closed lid must be accidental", "login id mustn't start with j".)
Yep, here I agree, the default policy needs care. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Wed, 26 Feb 2014 09:36:57 -0300, Cristian Rodríguez wrote:
El 26/02/14 03:30, Takashi Iwai escribió:
So, to repeat myself: - A fundamental service like logind must cover all use cases, no matter how major / minor it is.
I disagree, It is my belief (and I think upstream's as well) that logind should only support a set of most common use-cases only. not everything.
So, do we offer proper system setups without logind? If not, how such a use case can be supported by openSUSE? Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 26/02/14 10:03, Takashi Iwai escribió:
So, do we offer proper system setups without logind?
Nope. If not, how such
a use case can be supported by openSUSE?
Forgot to mention, I agree this _particular_ usecase needs better handling.. just reject the idea that _all_ usescases have to be covered. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Wed, 26 Feb 2014 10:42:19 -0300, Cristian Rodríguez wrote:
El 26/02/14 10:03, Takashi Iwai escribió:
So, do we offer proper system setups without logind?
Nope. If not, how such
a use case can be supported by openSUSE?
Forgot to mention, I agree this _particular_ usecase needs better handling.. just reject the idea that _all_ usescases have to be covered.
Sure, I also don't mean the perfectly all use cases, of course. We can't support the use case to throw your laptop as a Frisbee :) In my mind, it's all cases where it has worked before, at least. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26.02.2014 13:36, schrieb Cristian Rodríguez:
El 26/02/14 03:30, Takashi Iwai escribió:
So, to repeat myself: - A fundamental service like logind must cover all use cases, no matter how major / minor it is.
I disagree, It is my belief (and I think upstream's as well) that logind should only support a set of most common use-cases only. not everything.
Ok, then how can I get rid of logind? -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt <jengelh@inai.de> wrote:
On Tuesday 2014-02-25 18:45, Takashi Iwai wrote:
On Tuesday 25 February 2014 18:19:28 Takashi Iwai wrote:
What happens if a machine is booted with the lid closed (e.g. via WoL or a timer)? Will the machine go again to suspend immediately?
If the lid is closed and the machine is not docked (or docking is not detected), then yes the machine is directly suspended again.[...]
That's a very wrong assumption. An obvious counter case is to use a laptop as a server.
It may be a counter case, but not a very _common_ case.
Possibly not common, but I've done it. And the whole concept of using a raspberry pi as a server is similar. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Feb 25, 2014 at 8:06 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
Jan Engelhardt <jengelh@inai.de> wrote:
On Tuesday 2014-02-25 18:45, Takashi Iwai wrote:
On Tuesday 25 February 2014 18:19:28 Takashi Iwai wrote:
What happens if a machine is booted with the lid closed (e.g. via WoL or a timer)? Will the machine go again to suspend immediately?
If the lid is closed and the machine is not docked (or docking is not detected), then yes the machine is directly suspended again.[...]
That's a very wrong assumption. An obvious counter case is to use a laptop as a server.
It may be a counter case, but not a very _common_ case.
Possibly not common, but I've done it. And the whole concept of using a raspberry pi as a server is similar.
Isn't systemd's behavior disableable? If so, all this lappy-as-a-server thing is moot: just disable suspending on lid close. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 25 February 2014 20:18:36 Claudio Freire wrote:
Possibly not common, but I've done it. And the whole concept of using a raspberry pi as a server is similar. Isn't systemd's behavior disableable?
No. This is a built-in feature which can not be switched on or off by the user. The only way out would be to write a small program that creates an inhibit for systemd to activate the suspend upon lid close. This is what the major desktops have implemented, so that the desktop is in control of what happens. This is normally done in the powermanagers. However the systemd behavior already occurs long before the desktop environment is up, so an additional startup program would be needed. Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 26 February 2014, Raymond Wooninck wrote:
On Tuesday 25 February 2014 20:18:36 Claudio Freire wrote:
Possibly not common, but I've done it. And the whole concept of using a raspberry pi as a server is similar.
Isn't systemd's behavior disableable?
No. This is a built-in feature which can not be switched on or off by the user.
Is this a bad joke? It's really not possible to disable suspend on lid close? But hopefully it's still possible to disable suspend completely? cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 26 February 2014 11:39:03 Ruediger Meier wrote:
No. This is a built-in feature which can not be switched on or off by the user.
Is this a bad joke? It's really not possible to disable suspend on lid close? But hopefully it's still possible to disable suspend completely?
As indicated in my email, normally the desktop environment can place an inhibit systemd behavior regarding suspend, etc and that the powermanager of the desktop environment is handling these type of events. As I also indicated in the rest of my email, which you left out. So in short, as long as there is no desktop running, systemd will control the system and as far as I know there is no configuration file that controls the behavior of systemd. Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 26 Feb 2014 11:39:03 +0100 Ruediger Meier <sweet_f_a@gmx.de> wrote:
On Wednesday 26 February 2014, Raymond Wooninck wrote:
On Tuesday 25 February 2014 20:18:36 Claudio Freire wrote:
Possibly not common, but I've done it. And the whole concept of using a raspberry pi as a server is similar.
Isn't systemd's behavior disableable?
No. This is a built-in feature which can not be switched on or off by the user.
Is this a bad joke? It's really not possible to disable suspend on lid close? But hopefully it's still possible to disable suspend completely?
cu, Rudi
robert@viper:/etc/systemd> cat logind.conf |grep Lid #HandleLidSwitch=suspend #LidSwitchIgnoreInhibited=yes Isn't this the way to disable suspend on lid close in systemd? -- Robert Milasan L3 Support Engineer SUSE Linux (http://www.suse.com) email: rmilasan@suse.com GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Feb 26, 2014 at 7:58 AM, Robert Milasan <rmilasan@suse.com> wrote:
On Wed, 26 Feb 2014 11:39:03 +0100 Ruediger Meier <sweet_f_a@gmx.de> wrote:
On Wednesday 26 February 2014, Raymond Wooninck wrote:
On Tuesday 25 February 2014 20:18:36 Claudio Freire wrote:
Possibly not common, but I've done it. And the whole concept of using a raspberry pi as a server is similar.
Isn't systemd's behavior disableable?
No. This is a built-in feature which can not be switched on or off by the user.
Is this a bad joke? It's really not possible to disable suspend on lid close? But hopefully it's still possible to disable suspend completely?
cu, Rudi
robert@viper:/etc/systemd> cat logind.conf |grep Lid #HandleLidSwitch=suspend #LidSwitchIgnoreInhibited=yes
Isn't this the way to disable suspend on lid close in systemd?
I would think so. If not, I would venture that is a bug. Isn't it? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2/26/2014 5:58 AM, Robert Milasan wrote:
On Wed, 26 Feb 2014 11:39:03 +0100 Ruediger Meier <sweet_f_a@gmx.de> wrote:
On Wednesday 26 February 2014, Raymond Wooninck wrote:
On Tuesday 25 February 2014 20:18:36 Claudio Freire wrote:
Possibly not common, but I've done it. And the whole concept of using a raspberry pi as a server is similar.
Isn't systemd's behavior disableable?
No. This is a built-in feature which can not be switched on or off by the user.
Is this a bad joke? It's really not possible to disable suspend on lid close? But hopefully it's still possible to disable suspend completely?
cu, Rudi
robert@viper:/etc/systemd> cat logind.conf |grep Lid #HandleLidSwitch=suspend #LidSwitchIgnoreInhibited=yes
Isn't this the way to disable suspend on lid close in systemd?
And just to be clear, this can be done remotely from a serial console, CORRECT? For example, interactively add init=/bin/sh to the boot prompt in grub or syslinux, then from the shell edit the config file, then reboot? Plymouth or bootsplash or some other crap doesn't prevent it? Oh wait... what laptop has a bios capable of serial console redirection? They would have to either have an expensive ip-kvm hooked up, or require and expensive hands-on visit. Using a laptop as a server is rarely something someone does as a first choice. The point is, what is the excuse for removing a functionality, a dimension of flexibility, when all the people writing unix and linux have spent decades working so hard *pointedly* to make everything in the system so agnostic? And for that matter, old laptops and netbooks are perfect little routers and special purpose servers. They're not good for anything else after a little while. Who has any right to tell anyone else they should not do that? It's also an always-handy emergency measure that shouldn't just stop being available one day. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 18.11.2014 um 01:08 schrieb Brian K. White:
Oh wait... what laptop has a bios capable of serial console redirection?
All with intel vPro inside :-)
They would have to either have an expensive ip-kvm hooked up, or require and expensive hands-on visit.
No, they wouldn't. So even though I agree with some of your sentiments, you have to make up an even more obscure example to convince us :-) Have fun, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2014-02-26 00:06, Greg Freemyer wrote:
That's a very wrong assumption. An obvious counter case is to use a laptop as a server.
It may be a counter case, but not a very _common_ case.
Possibly not common, but I've done it. And the whole concept of using a raspberry pi as a server is similar.
There is yet a RPI to show up with a lid, though. And if there is a lid, you can change the behavior, as Claudio mentions. It's just a default. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, I do not know the full context of the whole thread, but: On Wednesday, February 26, 2014 01:25:47 AM Jan Engelhardt wrote:
On Wednesday 2014-02-26 00:06, Greg Freemyer wrote:
That's a very wrong assumption. An obvious counter case is to use a laptop as a server.
It may be a counter case, but not a very _common_ case.
Possibly not common, but I've done it. And the whole concept of using a raspberry pi as a server is similar.
There is yet a RPI to show up with a lid, though. And if there is a lid, you can change the behavior, as Claudio mentions. It's just a default.
Yes, please set the default to "not suspend on lid close", this feature annoyed me so often. I have a suspend button for suspending, every laptop nowadays has one. If I have my laptop connected to my television, I want to shut down the lid and continue watching the video (there are probably a hundred more examples). Adopting to Microsoft Windows when they invented this stupid behavior was wrong. My 2 cents, Thomas -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2014-02-27 14:31, Thomas Renninger wrote:
I do not know the full context of the whole thread, but: I have a suspend button for suspending, every laptop nowadays has one. If I have my laptop connected to my television, I want to shut down the lid and continue watching the video (there are probably a hundred more examples).
it has been stated that the presence of docking stations and external monitors is to be a suspend inhibition criterion. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 27.02.2014 18:34, schrieb Jan Engelhardt:
On Thursday 2014-02-27 14:31, Thomas Renninger wrote:
I do not know the full context of the whole thread, but: I have a suspend button for suspending, every laptop nowadays has one. If I have my laptop connected to my television, I want to shut down the lid and continue watching the video (there are probably a hundred more examples).
it has been stated that the presence of docking stations and external monitors is to be a suspend inhibition criterion.
I even close the lid after starting the DLNA audio renderer. Will this also be detected. What is so hard about "let the user decide and don't be a know-it-all-better-smartass"? -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26.02.2014 01:25, schrieb Jan Engelhardt:
On Wednesday 2014-02-26 00:06, Greg Freemyer wrote:
That's a very wrong assumption. An obvious counter case is to use a laptop as a server.
It may be a counter case, but not a very _common_ case.
Possibly not common, but I've done it. And the whole concept of using a raspberry pi as a server is similar.
There is yet a RPI to show up with a lid, though.
But there's lots of X86 hardware with broken Firmware. I have a desktop here which shows a (reportedly connected!) LVDS display, even though the only connector is a VGA cable, leading GDM to output the login window on the LVDS display. And the users wondering why the screen does stay black after boot. I'd almost bet that you can find desktop motherboards which pretend to have a lid switch (and which is of course always closed).
And if there is a lid, you can change the behavior, as Claudio mentions. It's just a default.
Well, that's different from what Raymound wrote. We'll see. A sensible openSUSE default would then be to disable all suspend by systemd and let the desktop environments handle it. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Fri, 28 Feb 2014 08:38:49 +0100, Stefan Seyfried wrote:
Am 26.02.2014 01:25, schrieb Jan Engelhardt:
On Wednesday 2014-02-26 00:06, Greg Freemyer wrote:
That's a very wrong assumption. An obvious counter case is to use a laptop as a server.
It may be a counter case, but not a very _common_ case.
Possibly not common, but I've done it. And the whole concept of using a raspberry pi as a server is similar.
There is yet a RPI to show up with a lid, though.
But there's lots of X86 hardware with broken Firmware.
I have a desktop here which shows a (reportedly connected!) LVDS display, even though the only connector is a VGA cable, leading GDM to output the login window on the LVDS display. And the users wondering why the screen does stay black after boot.
I'd almost bet that you can find desktop motherboards which pretend to have a lid switch (and which is of course always closed).
Right. Of course, they are minority. But there are. And, speaking of minority, we can't forget about Braille output. Would logind detect it dynamically? Yet another example: you boot (lid closed) with the connection to a TV while TV is powered off. Then no external monitor is detected, so the machine goes to suspend, because logind thinks you turned on the machine accidentally. There must be some reasons why such an action (checking the lid state at start up and going to suspend immediately) wasn't implemented in the desktop environment. It's different from closing the lid while running.
And if there is a lid, you can change the behavior, as Claudio mentions. It's just a default.
Well, that's different from what Raymound wrote.
We'll see. A sensible openSUSE default would then be to disable all suspend by systemd and let the desktop environments handle it.
I sincerely hope so... Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Feb 28, 2014 at 10:51 AM, Takashi Iwai <tiwai@suse.de> wrote:
Yet another example: you boot (lid closed) with the connection to a TV while TV is powered off. Then no external monitor is detected, so the machine goes to suspend, because logind thinks you turned on the machine accidentally.
There must be some reasons why such an action (checking the lid state at start up and going to suspend immediately) wasn't implemented in the desktop environment. It's different from closing the lid while running.
Problem is, you can't ever know if something like that was accidental or not. You have to assume. If a user regularly does that sort of thing, they have to consciously decide to disable the suspend-on-lid-switch thing, knowing they'll risk accidental boots inside backpacks when they do - but hey, if they're careful it's their choice. The software (any software) can't really know the difference between accidental and purposeful bootup with any degree of certainty, so user input is the only way to go. Hence, the only proposal that is needed assuming that .conf works as one would assume (I tried systemd's documentation and found little of use - for the amount of documentation it has, it's horribly structured to say the least), if it works like that, then yast needs an easy-to-use config option for users to switch. That's all. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Fri, 28 Feb 2014 14:03:19 -0300, Claudio Freire wrote:
On Fri, Feb 28, 2014 at 10:51 AM, Takashi Iwai <tiwai@suse.de> wrote:
Yet another example: you boot (lid closed) with the connection to a TV while TV is powered off. Then no external monitor is detected, so the machine goes to suspend, because logind thinks you turned on the machine accidentally.
There must be some reasons why such an action (checking the lid state at start up and going to suspend immediately) wasn't implemented in the desktop environment. It's different from closing the lid while running.
Problem is, you can't ever know if something like that was accidental or not. You have to assume.
If a user regularly does that sort of thing, they have to consciously decide to disable the suspend-on-lid-switch thing, knowing they'll risk accidental boots inside backpacks when they do - but hey, if they're careful it's their choice.
The software (any software) can't really know the difference between accidental and purposeful bootup with any degree of certainty, so user input is the only way to go.
Hence, the only proposal that is needed assuming that .conf works as one would assume (I tried systemd's documentation and found little of use - for the amount of documentation it has, it's horribly structured to say the least), if it works like that, then yast needs an easy-to-use config option for users to switch. That's all.
But how would you start YaST if you can't boot properly at all? You can't choose no matter how it's easy-to-use. No boot, no dice. I don't mind if the system boots up and reaches to the desktop environment properly, then it tries to react more smartly. Most of DEs have enough controls to adjust. It allows even different setups depending on the current user. But, when a lowlevel service like logind starts behaving too smart without knowing what's really doing (literally it cannot know, as you mentioned), it's a bigger problem. That said, if the system was once installed properly, and if user already chose the action such a case, this is the matter of configuration. But, deciding a too smart policy secretly out of sudden as default by a version update is no good way. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Feb 28, 2014 at 2:23 PM, Takashi Iwai <tiwai@suse.de> wrote:
Hence, the only proposal that is needed assuming that .conf works as one would assume (I tried systemd's documentation and found little of use - for the amount of documentation it has, it's horribly structured to say the least), if it works like that, then yast needs an easy-to-use config option for users to switch. That's all.
But how would you start YaST if you can't boot properly at all? You can't choose no matter how it's easy-to-use. No boot, no dice.
Save buggy firmware, I don't see how that can happen. If you see your laptop suspends when you close the lid, you keep the lid open till you changed the setting. There's no rocket science involved, my sister would be able to figure that out. Buggy firmware is another matter altogether. That would require some kernel-line-level switch I guess (like brokenmodules). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Fri, 28 Feb 2014 14:28:55 -0300, Claudio Freire wrote:
On Fri, Feb 28, 2014 at 2:23 PM, Takashi Iwai <tiwai@suse.de> wrote:
Hence, the only proposal that is needed assuming that .conf works as one would assume (I tried systemd's documentation and found little of use - for the amount of documentation it has, it's horribly structured to say the least), if it works like that, then yast needs an easy-to-use config option for users to switch. That's all.
But how would you start YaST if you can't boot properly at all? You can't choose no matter how it's easy-to-use. No boot, no dice.
Save buggy firmware, I don't see how that can happen. If you see your laptop suspends when you close the lid, you keep the lid open till you changed the setting. There's no rocket science involved, my sister would be able to figure that out.
Buggy firmware is another matter altogether. That would require some kernel-line-level switch I guess (like brokenmodules).
No, you missed the whole point. Suppose you set up logind in that way and boot a machine with the closed lid. Then it doesn't boot fully. It goes suspend immediately instead. That's the problem. It's no bug of firmware. It's just logind. So, again, how you would change the setup if you can't boot? You can't assume that the boot parameter can be changed, too. Some EFI loader doesn't allow it. Or, the machine is booted up remotely via WoL. So, we can't assume to open the lid physically. Remember that this can be introduced just by a systemd package update. Then you may have no chance to change the setup before falling into such a situation (or are you changing /etc/logind.conf at each systemd update?). Yes, this is a corner case. But disallowing such a basic operation like booting is a showstopper. That's why I've been suggesting to consider the default policy very carefully. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Feb 28, 2014 at 3:13 PM, Takashi Iwai <tiwai@suse.de> wrote:
Remember that this can be introduced just by a systemd package update. Then you may have no chance to change the setup before falling into such a situation (or are you changing /etc/logind.conf at each systemd update?).
That's probably the only case you'd care to think about. If it's a new installation, over the network, you expect the sysadmin to do his homework regarding that quite unusual setup. An update is another matter. Perhaps an update shouldn't change suspending behavior. There's just too many things that can go wrong suspending, not all of them knowable to software. For instance: a desktop that has a PSU unable to supply enough current on suspend state to power the RAM. It happens, such a set up would just crash when it enters the suspension state. Silently enabling suspension through a patch update is what's wrong here. The update should include a configuration that mimicks previous behavior (or at least some safe behavior). For new installations, though, you just leave the default. The sysadmin is responsible for checking whether the lid thing works correctly before leaving the system unattendable, especially since unreachable laptops really are a niche thing (perhaps only used for automated QA - the only use case I can think of). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Feb 28, 2014 at 12:21 PM, Claudio Freire <klaussfreire@gmail.com> wrote:
Silently enabling suspension through a patch update is what's wrong here. The update should include a configuration that mimicks previous behavior (or at least some safe behavior).
Exactly. Otherwise known as the principle of least astonishment: http://en.wikipedia.org/wiki/Principle_of_least_astonishment systemd has violated it in the past as well... like when my Ethernet interface was randomly renamed from eth0 to ens33, and a box that was 1,200 miles away from here became unreachable over the network (thanks for that one). -Archie -- Archie L. Cobbs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 28/02/14 15:25, Archie Cobbs escribió:
systemd has violated it in the past as well... like when my Ethernet
It is udev that does that, not systemd.. and has absolutely nothing to do with the topic we are discussing here. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Feb 28, 2014 at 12:39 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
El 28/02/14 15:25, Archie Cobbs escribió:
systemd has violated it in the past as well... like when my Ethernet
It is udev that does that, not systemd.. and has absolutely nothing to do with the topic we are discussing here.
Apologies if I misplaced blame, I'm just reading from (*). Whoever is to blame, this was still a serious violation of POLA. The point here is that it's good to fix real problems .. that's healthy progress. But in one's eagerness one should avoid creating new problems in order to fix old ones. Causing systems to fail to (re)boot, or not be able to talk on the network, is a serious problem. Can you not agree with that? (*) Quoting from http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterface... Starting with v197 systemd/udev will automatically assign predictable, stable network interface names for all local Ethernet, WLAN and WWAN interfaces. This is a departure from the traditional interface naming scheme ("eth0", "eth1", "wlan0", ...), but should fix real problems. -Archie -- Archie L. Cobbs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodr�������������������������������� wrote:
El 28/02/14 15:25, Archie Cobbs escribi�:
systemd has violated it in the past as well... like when my Ethernet
It is udev that does that, not systemd.. and has absolutely nothing to do with the topic we are discussing here.
You mean the udev that is part of systemd now? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2014-03-04 00:39, Linda Walsh wrote:
Cristian Rodr???????????????????????????????????????????????????????????????????????????????????????????????? wrote:
El 28/02/14 15:25, Archie Cobbs escribi???:
systemd has violated it in the past as well... like when my Ethernet
It is udev that does that, not systemd.. and has absolutely nothing to do with the topic we are discussing here.
You mean the udev that is part of systemd now?
They are still separate binaries and installables. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/03/2014 08:40 PM, Jan Engelhardt pecked at the keyboard and wrote:
On Tuesday 2014-03-04 00:39, Linda Walsh wrote:
Cristian Rodr???????????????????????????????????????????????????????????????????????????????????????????????? wrote:
El 28/02/14 15:25, Archie Cobbs escribi???:
systemd has violated it in the past as well... like when my Ethernet
It is udev that does that, not systemd.. and has absolutely nothing to do with the topic we are discussing here.
You mean the udev that is part of systemd now?
They are still separate binaries and installables.
It's not part of systemd but is called/controlled by systemd. Feb 22 18:50:48 toshiba-lt dbus[5342]: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service' -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 03/03/14 22:51, Ken Schneider - openSUSE escribió:
It's not part of systemd but is called/controlled by systemd.
Everything is ultimately controlled by the init system..that's the point whole point of it. Some of the non PID1 systemd helper binaries are consumers of udev, just like the rest of system.
Feb 22 18:50:48 toshiba-lt dbus[5342]: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service'
What has dbus activation to do with udev.. ? this is also a completely different thing. Even though there is a lot of documentation written it seems people remain seriously confused about a whole lot things. :-( -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/03/2014 09:04 PM, Cristian Rodríguez pecked at the keyboard and wrote:
El 03/03/14 22:51, Ken Schneider - openSUSE escribió:
It's not part of systemd but is called/controlled by systemd.
Everything is ultimately controlled by the init system..that's the point whole point of it.
Some of the non PID1 systemd helper binaries are consumers of udev, just like the rest of system.
Feb 22 18:50:48 toshiba-lt dbus[5342]: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service'
What has dbus activation to do with udev.. ? this is also a completely different thing.
Sorry, I meant to pull a line showing systemd interacting with udev. Such as: Feb 25 09:28:07 toshiba-lt kernel: 13.153574] systemd-udevd[307]: renamed network interface eth0 to enp1s0 -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Ken Schneider - openSUSE wrote:
It's not part of systemd but is called/controlled by systemd.
Sorry, I guess the the systemd-udevd man page had me thinking udevd was now a systemd-udevd... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Ken Schneider - openSUSE wrote:
On 03/03/2014 09:04 PM, Cristian Rodr�guez pecked at the keyboard and wrote:
El 03/03/14 22:51, Ken Schneider - openSUSE escribi�:
It's not part of systemd but is called/controlled by systemd.
Why is systemd required to control it? That's what I don't understand. Even Gvim had a dependency on systemd?!?! WT**? What about gvim requires systemd ??/ It's insane or bizarre or something.... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Fri, 28 Feb 2014 15:21:18 -0300, Claudio Freire wrote:
On Fri, Feb 28, 2014 at 3:13 PM, Takashi Iwai <tiwai@suse.de> wrote:
Remember that this can be introduced just by a systemd package update. Then you may have no chance to change the setup before falling into such a situation (or are you changing /etc/logind.conf at each systemd update?).
That's probably the only case you'd care to think about. If it's a new installation, over the network, you expect the sysadmin to do his homework regarding that quite unusual setup.
An update is another matter. Perhaps an update shouldn't change suspending behavior. There's just too many things that can go wrong suspending, not all of them knowable to software. For instance: a desktop that has a PSU unable to supply enough current on suspend state to power the RAM. It happens, such a set up would just crash when it enters the suspension state.
Silently enabling suspension through a patch update is what's wrong here. The update should include a configuration that mimicks previous behavior (or at least some safe behavior).
For new installations, though, you just leave the default. The sysadmin is responsible for checking whether the lid thing works correctly before leaving the system unattendable, especially since unreachable laptops really are a niche thing (perhaps only used for automated QA - the only use case I can think of).
Yes, the bigger question is about the update path. It must not break the working system, and this change would be a high risk. If the default setup of logind isn't changed (here I mean the real "default" -- the behavior when no config setup is given), the compatible behavior should be kept after the update since /etc/sysgmd.logind.conf is marked as %config(noreplace). OTOH, if the "default" behavior changes secretly, it'll be a problem. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 28.02.2014 18:28, schrieb Claudio Freire:
Buggy firmware is another matter altogether. That would require some kernel-line-level switch I guess (like brokenmodules).
brokenmodules=button will probably do, but it still is just a workaround for a fundamentally broken design. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt wrote:
On Tuesday 2014-02-25 18:45, Takashi Iwai wrote:
On Tuesday 25 February 2014 18:19:28 Takashi Iwai wrote:
What happens if a machine is booted with the lid closed (e.g. via WoL or a timer)? Will the machine go again to suspend immediately? If the lid is closed and the machine is not docked (or docking is not detected), then yes the machine is directly suspended again.[...] That's a very wrong assumption. An obvious counter case is to use a laptop as a server.
It may be a counter case, but not a very _common_ case.
I've heard it being frequently used by home users or SBU's as a lower-power option for a server with built-in UPS. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 02/25/2014 12:30 PM, Raymond Wooninck pecked at the keyboard and wrote:
On Tuesday 25 February 2014 18:19:28 Takashi Iwai wrote:
What happens if a machine is booted with the lid closed (e.g. via WoL or a timer)? Will the machine go again to suspend immediately?
If the lid is closed and the machine is not docked (or docking is not detected), then yes the machine is directly suspended again. As indicated yesterday morning I had this issue while trying to boot the system. Before I realized what exactly was happening, the system suspended already around 4 times. Only opening the lid "resolved" it and the system booted normally. So yes, in the future if there is no external monitor connected then the system will directly go into suspend state again as that the lid is closed. As Lennart describes it as an accidental power-on of the system.
The integrating the external monitor detection into logind doesn't look like a good solution to me. The external monitor detection isn't guaranteed to work always, even if the lid switch detection works. For example, you can delay the loading of KMS module (e.g. nomodeset due to driver breakage). Then the external monitor can't be detected. Meanwhile, the lid switch is reported by the input driver, so logind will catch it and tries to suspend. I hope we won't fall into such a stupid scenario...
Lennart indicated that he would start working on a solution after release of version 210. This is the direction that he indicated and I guess that more knowledgeable persons than me in this area could try to talk to him in finding the right solution.
It's too bad that the universities don't have the ability to teach common sense. :-) -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Ken Schneider - openSUSE wrote:
Lennart indicated that he would start working on a solution after release of version 210. This is the direction that he indicated and I guess that more knowledgeable persons than me in this area could try to talk to him in finding the right solution.
It's too bad that the universities don't have the ability to teach common sense. :-)
I used to think that using stable, proven technologies as default and making new, experimental technologies as options, was 'common sense', but that changed as well. Maybe he's showing the latest teachings?... ;-/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Raymond Wooninck writes:
Just a very early warning with regards to the latest released systemd version (version 210). In the release notes the following two items will have an effect on people that are utilizing laptops with a docking station and an external monitor. […]
Honestly, I don't think it is up to systemd or logind to decide what is supposed to happen in any of these cases. They ultimately need to handle whatever has been decided, but that decision needs to be taken outside these two processes. What you have described as current or suggested default policies doesn't strike me as particularly useful, measured by how I use my (usually docked in) laptop. Not only does one size fits _not_ all in this case, the desired policy is likely going to change even while the same user continues to be logged into the same session. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday, February 25, 2014 18:49:46 Achim Gratz wrote:
Raymond Wooninck writes:
Just a very early warning with regards to the latest released systemd version (version 210). In the release notes the following two items will have an effect on people that are utilizing laptops with a docking station and an external monitor.
[…]
Honestly, I don't think it is up to systemd or logind to decide what is supposed to happen in any of these cases. They ultimately need to handle whatever has been decided, but that decision needs to be taken outside these two processes. What you have described as current or suggested default policies doesn't strike me as particularly useful, measured by how I use my (usually docked in) laptop. Not only does one size fits _not_ all in this case, the desired policy is likely going to change even while the same user continues to be logged into the same session.
Regards, Achim.
Hi Achim, This is the reply from Lennart on the point already raised:
logind is now a lot more aggressive when suspending the machine due to a closed laptop lid. Instead of acting only on the lid close action it will continuously watch the lid status and act on it. This is useful for laptops where the power button is on the outside of the chassis so that it can be reached without opening the lid (such as the Lenovo Yoga). On those machines logind will now immediately re-suspend the machine if the power button has been accidentally pressed while the laptop was suspended and in a backpack or similar.
What about being able to run laptops lid-closed as long as there's an external display and input device? I don't personally do this, but I'm curious how widely it might be needed.
What we'll probably do is two things: 1) Enumerate connected displays in logind from sysfs and inhibit lid close suspends if a number != 1 is found. 2) Avoid suspend due to lid close for 1min after the last suspend and 3min after boot or so. Thing #1 has been traditionally done by GNOME which took an inhibitor lock when it detected multiple connected displays. We probably should move this one layer down into logind to open this up for other DEs and more importantly to close the race where GNOME would be started after logind which means the inhibitor lock GNOME could take would be too late to make sure logind doesn't already suspend due to the lid closed. Thing #2 is then necessary to cover for USB docking stations for which we simply never know when they fully reappear after a supend or at boot, since that's unbounded on USB. Of course this rule #2 isn't that great on my own Yoga laptop, since it means if I by accident power on the laptop in my backpack it will only resuspend after 1min instead of instantly... But I figure that's the price to pay for being general purpose. Those two items are now on the TODO list. Lennart -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (16)
-
Achim Gratz -
Archie Cobbs -
Brian K. White -
Claudio Freire -
Cristian Rodríguez -
Greg Freemyer -
Jan Engelhardt -
Jason -
Ken Schneider - openSUSE -
Linda Walsh -
Raymond Wooninck -
Robert Milasan -
Ruediger Meier -
Stefan Seyfried -
Takashi Iwai -
Thomas Renninger