Control: tags -1 + moreinfo On Sun, 20 Jan 2019 at 08:55:23 -0800, Josh Triplett wrote: > I disable suspend on lid close, but I *always* need the screen to lock > when I close the lid.
This seems like an inherently "unstable" pattern: whatever the precise design/meaning of this "tweak" might have been intended to be, you're relying on the screen locking under precisely those conditions in which you can't tell whether it has really happened, so any bugs or mismatched expectations become highly problematic. If screen locking is important to you, then either getting into the habit of explicitly locking the screen with Super+L (Windows+L), or reverting to the default suspend-on-lid-close, would be considerably safer. With explicit locking, you can see that the screen has indeed locked before you close the lid; with suspend-on-lid-close, most laptops have a visible indication that they have indeed suspended (for example a power LED switching from constantly-on to flashing or pulsing), and GNOME and logind cooperate to ensure that the screen locks before this can happen. As a result, I am not sure that "grave" severity is really justified here. Would it address your concern if the option in gnome-tweaks was renamed to "Ignore laptop lid being closed", with its sense reversed? That's what is really happening behind the scenes (gnome-tweaks installs an inhibitor for the handle-lid-switch logind event). On Sun, 07 Apr 2019 at 19:25:40 +0200, intrigeri wrote: > FWIW the patch proposed upstream applies nicely on top of our > debian/unstable branch: > https://salsa.debian.org/gnome-team/gnome-settings-daemon/merge_requests/3 > > I probably won't have time to test this myself in the next few days. > Hoping this WIP MR might save someone else a tiny bit of time :) Does this patch provide the behaviour you want? It looks as though the patch has not been accepted upstream because there is a concern that it breaks other valid use cases, possibly involving tablet or 2-in-1 PCs locking and suspending when they should have locked but continued to run (I'm not sure of the precise details). As a result, if we diverge from upstream on this, we should be aware that we might be causing important regressions. (Also, I personally have my laptop configured to not suspend on lid close, and expect this to *not* lock the screen: I press the suspend or screen-lock hotkey if I'm going to stop using it, or close the lid without doing either of those if I'm going to carry it to another room and continue to use it. The proposed change would break this; I wouldn't say that that's a particularly important regression, so I wouldn't want to block the patch being applied if there is consensus that it is correct, but it *is* a regression.) smcv
