GNU bug report logs -
#57052
elogind-service specifies a variable that's ignored by defualt
Previous Next
Reported by: Cairn <cairn <at> pm.me>
Date: Mon, 8 Aug 2022 07:20:01 UTC
Severity: normal
Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Hi,
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
> Hi,
>
> Liliana Marie Prikler <liliana.prikler <at> 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 <at> nckx>. It had fallen into the cracks, it
seems.
Maxim
This bug report was last modified 2 years and 364 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.