After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 743455 - Suspend when clicking "Lock screen" on tablets
Suspend when clicking "Lock screen" on tablets
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: system-status
3.15.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
touch
Depends on:
Blocks:
 
 
Reported: 2015-01-24 23:59 UTC by Bastien Nocera
Modified: 2021-07-05 14:07 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bastien Nocera 2015-01-24 23:59:02 UTC
When the Chassis property of org.freedesktop.hostname1 is "tablet", and suspend is available (hopefully should be), the "Lock screen" button should act as "Lock screen + suspend".

On tablets that lack a real suspend mode ("suspending" will put all the processes in the freezer, it won't go into another firmware mode), locking the screen should be equivalent to "I'll stop using this device". In the future, the proposed "Lock screen + suspend" would become "Lock screen + put all the applications in the freezer but still allow network connections every now and then to get my twitter notifications".

I'll also note that we now disable touchscreens when the screensaver is on, and the screen off.

This change also means that we don't get a case, for devices without a physical button to "wake up the screen" (a physical home button, or Windows button), where the touchscreen is off, and the only button that would do something is the suspend button, sending the machine into suspend instead of waking it up. And for machines with a Home button, having a Schödinger's system, where the user doesn't know whether they need to press the Home button (which won't wake it up when suspended) or the Power button (which will send it to suspend if it's only the screensaver that's on).

A similar change will need to happen in gnome-settings-daemon.
Comment 1 Bastien Nocera 2015-01-25 00:02:00 UTC
Cosimo, I'd appreciate comments on this, whether you think that's the right way to get a solution for this problem.

Allan, could we get this bug added to the 3.16 target? It's a small enough change that should make a big difference for GNOME tablets.
Comment 2 Bastien Nocera 2015-01-25 07:32:00 UTC
Actually, the patch in bug 743456 should be enough.
Comment 3 Cosimo Cecchi 2015-01-26 14:35:07 UTC
When the physical button is pressed, I expect the tablet to indeed suspend.
One caveat is that I don't think we want to expose "lock" and "suspend" as two separate actions in the UI in that case. Perhaps the "lock" button should just be the "suspend" button in that case, i.e. use the suspend icon etc.
With the way this is implemented in g-s-d I also worry that setting the brightness to zero (e.g. with the slider) will suspend the tablet, which is not what I'd expect - perhaps that's not a concern but putting the slider to zero seems to make the screen completely black on my laptop.
Comment 4 Bastien Nocera 2015-01-26 14:47:39 UTC
(In reply to comment #3)
> When the physical button is pressed, I expect the tablet to indeed suspend.
> One caveat is that I don't think we want to expose "lock" and "suspend" as two
> separate actions in the UI in that case. Perhaps the "lock" button should just
> be the "suspend" button in that case, i.e. use the suspend icon etc.

Sure. At least it's a small enough UI change, rather than the complicated suggestion I made in comment 0.

> With the way this is implemented in g-s-d I also worry that setting the
> brightness to zero (e.g. with the slider) will suspend the tablet, which is not
> what I'd expect - perhaps that's not a concern but putting the slider to zero
> seems to make the screen completely black on my laptop.

It will not, as it doesn't go through the same code path, you should be able to test it on a tablet. It won't happen on a laptop at all.
Comment 5 Cosimo Cecchi 2015-01-27 10:33:28 UTC
(In reply to comment #4)

> It will not, as it doesn't go through the same code path, you should be able to
> test it on a tablet. It won't happen on a laptop at all.

Cool; I think I was just confused by the name of the method backlight_disable().
Comment 6 Emre Erenoglu 2016-11-07 05:30:03 UTC
Hi, I'm using a Surface Pro 3. It's a tablet and a normal computer at the same time.
I'm running Gnome 3.22 from Arch repositories. Whenever I want to lock my system, through UI buttons (ie when leaving my desk), it locks AND suspends.

I do not want it to suspend, only to lock, but it's not possible today.

Is this bug related to my issue?
Comment 7 Jani Nikula 2017-02-27 09:37:56 UTC
(In reply to Emre Erenoglu from comment #6)
> Hi, I'm using a Surface Pro 3. It's a tablet and a normal computer at the
> same time.
> I'm running Gnome 3.22 from Arch repositories. Whenever I want to lock my
> system, through UI buttons (ie when leaving my desk), it locks AND suspends.
> 
> I do not want it to suspend, only to lock, but it's not possible today.
> 
> Is this bug related to my issue?

Yes. See bug 764723 and bug 779300.
Comment 8 GNOME Infrastructure Team 2021-07-05 14:07:37 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.