* bug#57052: elogind-service specifies a variable that's ignored by defualt @ 2022-08-07 23:29 Cairn via Bug reports for GNU Guix 2022-08-08 10:45 ` Liliana Marie Prikler 0 siblings, 1 reply; 10+ messages in thread From: Cairn via Bug reports for GNU Guix @ 2022-08-07 23:29 UTC (permalink / raw) To: 57052 [-- Attachment #1.1: Type: text/plain, Size: 569 bytes --] "HandleLidSwitchExternalPower= is completely ignored by default (for backwards compatibility)"[1] I noticed (with help in IRC) that my laptop wasn't suspending on lid close when plugged in and charging, which I hadn't seen happen on other systems. I now know that I can set this by configuring the `elogind-service` parameter `handle-lid-switch-external-power`. Regardless, it seems like it should default to being unset rather than set/ignored, since that would heed the line I quoted above. [1]: https://www.freedesktop.org/software/systemd/man/logind.conf.html [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 855 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#57052: elogind-service specifies a variable that's ignored by defualt 2022-08-07 23:29 bug#57052: elogind-service specifies a variable that's ignored by defualt Cairn via Bug reports for GNU Guix @ 2022-08-08 10:45 ` Liliana Marie Prikler 2022-08-09 1:52 ` bokr ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Liliana Marie Prikler @ 2022-08-08 10:45 UTC (permalink / raw) To: Cairn, 57052 Am Sonntag, dem 07.08.2022 um 23:29 +0000 schrieb Cairn: > "HandleLidSwitchExternalPower= is completely ignored by default (for > backwards compatibility)"[1] > > I noticed (with help in IRC) that my laptop wasn't suspending on lid > close when plugged in and charging, which I hadn't seen happen on > other systems. I now know that I can set this by configuring the > `elogind-service` parameter `handle-lid-switch-external-power`. > Regardless, it seems like it should default to being unset rather > than set/ignored, since that would heed the line I quoted above. I think you're misreading that line. What it states is not that "HandleLidSwitchExternalPower" is ignored by default, but "HandleLidSwitchExternalPower=" is ignored by default, i.e. there will be no value unless one was provided (whichever semantics "no value" has later on) is only confusingly explained later on. IMHO the Guix behaviour of always setting a value is the right one (explicit is better than implicit after all). As for the default values, one might disagree as to which fits, but I don't think ignoring lid switches while powered is harmful. Cheers ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#57052: elogind-service specifies a variable that's ignored by defualt 2022-08-08 10:45 ` Liliana Marie Prikler @ 2022-08-09 1:52 ` bokr 2022-08-09 6:34 ` Liliana Marie Prikler 2022-08-09 6:42 ` Cairn via Bug reports for GNU Guix 2022-08-09 13:52 ` Maxim Cournoyer 2 siblings, 1 reply; 10+ messages in thread From: bokr @ 2022-08-09 1:52 UTC (permalink / raw) To: Liliana Marie Prikler; +Cc: Cairn, 57052 Hi Liliana, On +2022-08-08 12:45:10 +0200, Liliana Marie Prikler wrote: > Am Sonntag, dem 07.08.2022 um 23:29 +0000 schrieb Cairn: > > "HandleLidSwitchExternalPower= is completely ignored by default (for > > backwards compatibility)"[1] > > > > I noticed (with help in IRC) that my laptop wasn't suspending on lid > > close when plugged in and charging, which I hadn't seen happen on > > other systems. I now know that I can set this by configuring the > > `elogind-service` parameter `handle-lid-switch-external-power`. > > Regardless, it seems like it should default to being unset rather > > than set/ignored, since that would heed the line I quoted above. > I think you're misreading that line. What it states is not that > "HandleLidSwitchExternalPower" is ignored by default, but > "HandleLidSwitchExternalPower=" is ignored by default, i.e. there will > be no value unless one was provided (whichever semantics "no value" has > later on) is only confusingly explained later on. > > IMHO the Guix behaviour of always setting a value is the right one > (explicit is better than implicit after all). As for the default > values, one might disagree as to which fits, but I don't think ignoring > lid switches while powered is harmful. > What would you advise if there's no battery power, or for some reason one is running on plug power only, for worriers that the bulding power might fail? I'd guess a power brick would power for some milliseconds and wonder if this is detectable, i.e., to do something at least to leave a goodbye world message somewhere if the machine was not suspended with sufficient state to resume after power restore? Buy a UPS, and don't go away long enough for that to run out? :) > Cheers > -- Regards, Bengt Richter ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#57052: elogind-service specifies a variable that's ignored by defualt 2022-08-09 1:52 ` bokr @ 2022-08-09 6:34 ` Liliana Marie Prikler 0 siblings, 0 replies; 10+ messages in thread From: Liliana Marie Prikler @ 2022-08-09 6:34 UTC (permalink / raw) To: bokr; +Cc: Cairn, 57052 Am Dienstag, dem 09.08.2022 um 03:52 +0200 schrieb bokr@bokr.com: > Hi Liliana, > > On +2022-08-08 12:45:10 +0200, Liliana Marie Prikler wrote: > > Am Sonntag, dem 07.08.2022 um 23:29 +0000 schrieb Cairn: > > > "HandleLidSwitchExternalPower= is completely ignored by default > > > (for > > > backwards compatibility)"[1] > > > > > > I noticed (with help in IRC) that my laptop wasn't suspending on > > > lid > > > close when plugged in and charging, which I hadn't seen happen on > > > other systems. I now know that I can set this by configuring the > > > `elogind-service` parameter `handle-lid-switch-external-power`. > > > Regardless, it seems like it should default to being unset rather > > > than set/ignored, since that would heed the line I quoted above. > > I think you're misreading that line. What it states is not that > > "HandleLidSwitchExternalPower" is ignored by default, but > > "HandleLidSwitchExternalPower=" is ignored by default, i.e. there > > will > > be no value unless one was provided (whichever semantics "no value" > > has > > later on) is only confusingly explained later on. > > > > IMHO the Guix behaviour of always setting a value is the right one > > (explicit is better than implicit after all). As for the default > > values, one might disagree as to which fits, but I don't think > > ignoring lid switches while powered is harmful. > > > > What would you advise if there's no battery power, > or for some reason one is running on plug power only, > for worriers that the bulding power might fail? > > I'd guess a power brick would power for some milliseconds > and wonder if this is detectable, i.e., to do something > at least to leave a goodbye world message somewhere if the machine > was not suspended with sufficient state to resume after power > restore? > > Buy a UPS, and don't go away long enough for that to run out? :) I do think that we're starting to split hairs here, but for the sake of the argument, elogind should be able to detect whether or not the power supply it's attached to actually delivers power. If your laptop doesn't have a battery, then pulling the plug on it has the same effects as pulling the plug on a regular PC, there's nothing you can do in elogind to make that a safe action. Cheers ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#57052: elogind-service specifies a variable that's ignored by defualt 2022-08-08 10:45 ` Liliana Marie Prikler 2022-08-09 1:52 ` bokr @ 2022-08-09 6:42 ` Cairn via Bug reports for GNU Guix 2022-08-09 13:52 ` Maxim Cournoyer 2 siblings, 0 replies; 10+ messages in thread From: Cairn via Bug reports for GNU Guix @ 2022-08-09 6:42 UTC (permalink / raw) To: Liliana Marie Prikler, 57052@debbugs.gnu.org [-- Attachment #1.1: Type: text/plain, Size: 746 bytes --] (Resending this email, since I forgot to add the debugs.gnu.org address as a recipient) > IMHO the Guix behaviour of always setting a value is the right one > (explicit is better than implicit after all). As for the default > values, one might disagree as to which fits, but I don't think ignoring > lid switches while powered is harmful. That's fair! Well, if explicitly setting variables is the standard, then I suggest changing `handle-lid-switch-external-power` to the same value as `handle-lid-switch` ("suspend"). I agree that the current setting isn't harmful, but this change would match the default, unconfigured behavior of `elogind`. It would also be more consistent with other distros' defaults from what I've experienced. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 855 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#57052: elogind-service specifies a variable that's ignored by defualt 2022-08-08 10:45 ` Liliana Marie Prikler 2022-08-09 1:52 ` bokr 2022-08-09 6:42 ` Cairn via Bug reports for GNU Guix @ 2022-08-09 13:52 ` Maxim Cournoyer 2022-08-09 13:57 ` Maxim Cournoyer 2 siblings, 1 reply; 10+ messages in thread From: Maxim Cournoyer @ 2022-08-09 13:52 UTC (permalink / raw) To: Liliana Marie Prikler; +Cc: Cairn, 57052 Hi, Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> writes: > Am Sonntag, dem 07.08.2022 um 23:29 +0000 schrieb Cairn: >> "HandleLidSwitchExternalPower= is completely ignored by default (for >> backwards compatibility)"[1] >> >> I noticed (with help in IRC) that my laptop wasn't suspending on lid >> close when plugged in and charging, which I hadn't seen happen on >> other systems. I now know that I can set this by configuring the >> `elogind-service` parameter `handle-lid-switch-external-power`. >> Regardless, it seems like it should default to being unset rather >> than set/ignored, since that would heed the line I quoted above. > I think you're misreading that line. What it states is not that > "HandleLidSwitchExternalPower" is ignored by default, but > "HandleLidSwitchExternalPower=" is ignored by default, i.e. there will > be no value unless one was provided (whichever semantics "no value" has > later on) is only confusingly explained later on. > > IMHO the Guix behaviour of always setting a value is the right one > (explicit is better than implicit after all). As for the default > values, one might disagree as to which fits, but I don't think ignoring > lid switches while powered is harmful. It can be. I have a Lenovo T430s with a partially discolored LCD from heat after I left it closed in a backpack for a couple hours, thinking it would have suspend (it was not). That would not have happened with the value supposed to be default (which matches the behavior used on most other systems). So I'd favor having the default to suspend on any lid close. Thanks, Maxim ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#57052: elogind-service specifies a variable that's ignored by defualt 2022-08-09 13:52 ` Maxim Cournoyer @ 2022-08-09 13:57 ` Maxim Cournoyer 2022-08-09 14:31 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 0 siblings, 1 reply; 10+ messages in thread From: Maxim Cournoyer @ 2022-08-09 13:57 UTC (permalink / raw) To: Liliana Marie Prikler; +Cc: Cairn, 57052 Hi, Maxim Cournoyer <maxim.cournoyer@gmail.com> writes: > Hi, > > Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> writes: > >> Am Sonntag, dem 07.08.2022 um 23:29 +0000 schrieb Cairn: >>> "HandleLidSwitchExternalPower= is completely ignored by default (for >>> backwards compatibility)"[1] >>> >>> I noticed (with help in IRC) that my laptop wasn't suspending on lid >>> close when plugged in and charging, which I hadn't seen happen on >>> other systems. I now know that I can set this by configuring the >>> `elogind-service` parameter `handle-lid-switch-external-power`. >>> Regardless, it seems like it should default to being unset rather >>> than set/ignored, since that would heed the line I quoted above. >> I think you're misreading that line. What it states is not that >> "HandleLidSwitchExternalPower" is ignored by default, but >> "HandleLidSwitchExternalPower=" is ignored by default, i.e. there will >> be no value unless one was provided (whichever semantics "no value" has >> later on) is only confusingly explained later on. >> >> IMHO the Guix behaviour of always setting a value is the right one >> (explicit is better than implicit after all). As for the default >> values, one might disagree as to which fits, but I don't think ignoring >> lid switches while powered is harmful. > > It can be. I have a Lenovo T430s with a partially discolored LCD from > heat after I left it closed in a backpack for a couple hours, thinking > it would have suspend (it was not). That would not have happened with > the value supposed to be default (which matches the behavior used on > most other systems). > > So I'd favor having the default to suspend on any lid close. For the record, this was noticed and discussed more than a year ago, see Message-ID: <871rens9a2.fsf@nckx>. It had fallen into the cracks, it seems. Maxim ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#57052: elogind-service specifies a variable that's ignored by defualt 2022-08-09 13:57 ` Maxim Cournoyer @ 2022-08-09 14:31 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 2022-08-09 14:42 ` Cairn via Bug reports for GNU Guix 0 siblings, 1 reply; 10+ messages in thread From: Tobias Geerinckx-Rice via Bug reports for GNU Guix @ 2022-08-09 14:31 UTC (permalink / raw) To: 57052, maxim.cournoyer, liliana.prikler; +Cc: cairn >For the record, this was noticed and discussed more than a year ago, see >Message-ID: <871rens9a2.fsf@nckx>. It had fallen into the cracks LOL. I'm the one who asked Cairn to report this. I didn't remember publicly reporting it, I only remembered noticing it and not fixing it, and didn't want it to get forgotten 'again'. Sorry for the noise! Strongly disagree that the current Guix behaviour makes any sense, let alone better! That sounds like posthockholm rationalisation to me. If people want opinionated variants, those can be written on top of a service that properly exposes upstream behaviour. Kind regards, T G-R Sent on the go. Excuse or enjoy my brevity. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#57052: elogind-service specifies a variable that's ignored by defualt 2022-08-09 14:31 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix @ 2022-08-09 14:42 ` Cairn via Bug reports for GNU Guix 2022-08-10 4:38 ` Maxim Cournoyer 0 siblings, 1 reply; 10+ messages in thread From: Cairn via Bug reports for GNU Guix @ 2022-08-09 14:42 UTC (permalink / raw) To: 57052@debbugs.gnu.org [-- Attachment #1.1: Type: text/plain, Size: 175 bytes --] Would it not still be explicit if variables that should go unspecified were written out, but not given a value? Maybe I'm misunderstanding the point of explicit values though. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 855 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#57052: elogind-service specifies a variable that's ignored by defualt 2022-08-09 14:42 ` Cairn via Bug reports for GNU Guix @ 2022-08-10 4:38 ` Maxim Cournoyer 0 siblings, 0 replies; 10+ messages in thread From: Maxim Cournoyer @ 2022-08-10 4:38 UTC (permalink / raw) To: Cairn; +Cc: liliana.prikler, 57052-done, Tobias Geerinckx-Rice Hello, Cairn <cairn@pm.me> writes: > Would it not still be explicit if variables that should go unspecified > were written out, but not given a value? Maybe I'm misunderstanding > the point of explicit values though. I made it *unspecified* in 59ee837d8b, given this service config doesn't yet use 'define-configuration' that would have allowed for a proper maybe-value. Tested to work on a X200 and pushed! Closing, at last. Thanks, Maxim ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2022-08-10 4:39 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-08-07 23:29 bug#57052: elogind-service specifies a variable that's ignored by defualt Cairn via Bug reports for GNU Guix 2022-08-08 10:45 ` Liliana Marie Prikler 2022-08-09 1:52 ` bokr 2022-08-09 6:34 ` Liliana Marie Prikler 2022-08-09 6:42 ` Cairn via Bug reports for GNU Guix 2022-08-09 13:52 ` Maxim Cournoyer 2022-08-09 13:57 ` Maxim Cournoyer 2022-08-09 14:31 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 2022-08-09 14:42 ` Cairn via Bug reports for GNU Guix 2022-08-10 4:38 ` Maxim Cournoyer
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).