Recently, disabling the setting "Suspend when laptop lid is closed"
seems to have started preventing *any* action on lid close, including
locking the screen; disabling that setting adds a startup file to run
/usr/lib/gnome-tweak-tool/gnome-tweak-tool-lid-inhibitor, which inhibits
*any* action on the lid switch. This is a security issue.

I disable suspend on lid close, but I *always* need the screen to lock
when I close the lid.

Hi Josh,

Josh Triplett:

Would you be interested in testing whether
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/merge_requests/84
fixes this problem for you?

Cheers,

intrigeri:

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 :)

Cheers,

Control: tags -1 + moreinfo
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).

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

user debian-release@lists.debian.org
usertags 919914 + bsp-2019-04-ca-toronto
thanks

We did some systematic tests and believe it is a bug in the integration
between gnome-tweaks and gnome-settings-daemon (Privacy -> Screen Lock
option). We still considered the status of the Power saving settings,
blank screen, check below.

I) Behavior on closing the lid

a) Tweaks: "Suspend when laptop lid is closed" OFF

"Automatic screen lock OFF" --> OK
"Automatic lock: After screen turns off" --> FAIL *** this was the bug
reported ***
"Automatic lock: After blank for X minutes: check passed X" --> FAIL
"Automatic lock: After blank for X minutes: check before X" --> OK (no
block)

b) Tweaks: "Suspend when laptop lid is closed" ON

"Automatic screen lock OFF" --> OK
"Automatic lock: After screen turns off" -.> OK
"Automatic lock: After blank for X minutes: check passed X" --> OK
"Automatic lock: After blank for X minutes: check before X" --> FAIL
(already blocked before X)

II) Behavior on inactivity

c) Power saving: "Blank screen after X minute"
   Laptop lid position: OPEN
   Privacy:

"Automatic screen lock OFF" --> OK
"Automatic lock: After screen turns off" -.> OK
"Automatic lock: After blank for X minutes: check passed X" --> OK
"Automatic lock: After blank for X minutes: check before X" --> OK (no
block)

d) Power saving: "Blank screen after X minute:
   Laptop lid position: CLOSED
   Privacy:

"Automatic screen lock OFF" --> OK
"Automatic lock: After screen turns off" --> OK
"Automatic lock: After blank for X minutes: check passed X" --> OK
"Automatic lock: After blank for X minutes: check before X" --> FAIL
(already blocked before X)


we hope this helps!

Tassia & Valessio.

Please could you describe precisely what these tests mean, and
particularly the cases you describe as failing? If the behaviour you
expect doesn't match the behaviour that was intended, I don't want to be
"fixing" things that are behaving as designed.

(In terms of: steps to reproduce; what you expected to happen; what
actually happened.)

Thanks,
    smcv

Sure. Please check below more info on each case described as a failure
in my previous message.

Failure #1

- To reproduce: Gnome-Tweaks configuration "Suspend when laptop lid is
closed" turned OFF. Gnome-settings Privacy option "Automatic lock" is
turned ON, and "After screen turns off". Close the lid.
- Expected: when the lid is closed, the laptop should not suspend, but
when the lid is re-opened the screen should be locked, asking for
authentication.
- What happens: No suspend, and no authentication required. ***this was
the situation described when the bug was opened***

Failure #2

- To reproduce: Gnome-Tweaks configuration "Suspend when laptop lid is
closed" turned OFF. Gnome-settings Privacy option "Automatic lock" is
turned ON, and "After blank for X minutes". Close the lid and wait for X
minutes.
- Expected: when the lid is closed, the laptop should not suspend, but
after X minutes have passed, the lid is re-opened and the screen should
be locked, asking for authentication.
- What happens: No suspend, and no authentication required, even after X
minutes have passed.

Failure #3

- To reproduce: Gnome-Tweaks configuration "Suspend when laptop lid is
closed" turned ON. Gnome-settings Privacy option "Automatic lock" is
turned ON, and "After blank for X minutes". Close the lid and re-open
before the X minutes have passed.
- Expected: when the lid is closed, the laptop should suspend, but only
after X minutes have passed that the screen should be locked. If the lid
is open before X minutes, I would expect it to not be locked.
- What happens: suspend is OK, but screen is locked right away, even
before the X minutes.

Failure #4

- To reproduce: Gnome-settings power saving is configured "Blank screen
after X minutes". Gnome-settings Privacy option "Automatic lock" is
turned ON, and "After blank for Y minutes". Close the lid and re-open
before the X+Y minutes have passed.
- Expected: when the laptop is inactive for X minutes, the screen should
blank, but only after extra Y minutes that the screen should be locked.
If the lid is open before X+Y minutes, I would expect it to not be
locked.
- What happens: but screen is locked right after blank, even before the
X+Y minutes.

Let me know if anything is still not clear.
Cheers,

Tassia.

This is (at least arguably) a bug.

So's this. While the lid is closed, the screen is blanked (because it
would be useless to leave it on, and possibly also to avoid heat from
the backlight building up), so time-based screen blanking doesn't happen,
which probably has the side-effect of not running the timer that counts
how long the screen has been blank.

I think this one is working as expected. Suspending always locks the
screen immediately (before actually suspending, in fact), because at
the time of suspending, the laptop cannot know how much time will pass
while suspended (it might be more than X minutes); and while the laptop
is suspended, processes do not run, so there is no opportunity to lock
the screen.

Older versions of GNOME only locked the screen after resuming from
suspend, but this was a security-relevant bug, which was fixed by better
logind integration: opening the lid to resume the laptop caused user
apps to appear briefly before the screen locked, and an attacker could
see (possibly confidential) window contents during that time.

With "Suspend when laptop lid is closed" turned on or off?

If it suspends, then I think this is working as expected, as in case 3.

    smcv