RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1643501 - RFE: Provide a supported method for disabling Gnome screen shield
Summary: RFE: Provide a supported method for disabling Gnome screen shield
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gnome-shell
Version: 7.5
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Florian Müllner
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On: 1720534
Blocks: 1656436
TreeView+ depends on / blocked
 
Reported: 2018-10-26 12:09 UTC by afox@redhat.com
Modified: 2019-08-06 12:38 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-06 12:37:45 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:2044 0 None None None 2019-08-06 12:38:19 UTC

Description afox@redhat.com 2018-10-26 12:09:01 UTC 
1. Proposed title of this feature request
Provide a supported method for disabling Gnome screen shield

2. Who is the customer behind the request?
Account: Met Office (748231)
TAM customer: Yes
SRM customer: Yes
Strategic: Yes

3. What is the nature and description of the request?

Customer is in the process of moving users to a Virtual Desktop Infrastructure (VDI) solution (currently VMWare Horizon) and as part of this they are disabling the screen saver and screen lock as it is not required - the users already have a screen lock and screen saver on the laptops they access the VDI platform with.

Unfortunately, the screen shield/cover does still operate and does still appear. This is frustrating for users as they have to press another key before they are able to proceed to do something (actually they can press any key, but there is no knowing which window has focus so no indication as to which script that they are writing will get the extra key press in it).

On these virtual desktops, the screen shield/cover really is redundant as it:
* doesn't display anything to the users that they can't already see
* doesn't hide anything from prying eyes as the laptop screen blanking does that

In fact, it actively obstructs the user experience on these machines.

Customer would therefore like to be able to disable the screen shield/cover on systems that have no requirement of this feature.

4. Why does the customer need this? (List the business requirements here)
See above description. 

5. How would the customer like to achieve this? (List the functional requirements here)
A simple on/off toggle within the Gnome environment would be sufficient. 
Currently, the customer is using a third party extension (https://extensions.gnome.org/extension/672/disable-screen-shield/) for this, but maintenance of this extension has ceased and there is no guarantee that it will continue to function beyond Gnome 3.28.2. 

6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
If screen shield no longer appears when toggle is set to disable. 

7. Is there already an existing RFE upstream or in Red Hat Bugzilla?
Not that I can find.

8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL6, RHEL7)?

As soon as possible.

9. Is the sales team involved in this request and do they have any additional input?
No. 

10. List any affected packages or components.
Gnome Shell

11. Would the customer be able to assist in testing this functionality if implemented?
Yes.
Comment 3 Vladimir Benes 2018-10-30 12:32:25 UTC 
does this help?
gsettings set org.gnome.desktop.lockdown disable-lock-screen true
gsettings set org.gnome.settings-daemon.plugins.power idle-dim false
gsettings set org.gnome.desktop.session idle-delay 0

I think it should.
Comment 4 afox@redhat.com 2018-11-15 16:20:55 UTC 
I've just checked and the customer already has these settings set to these values on the systems that they wish the screen shield to not be on. I can confirm that these machines still require the extra key press or "clicking and dragging the screen up" in order to get to the desktop or a login screen.

Is there another way that they can try, or will there be something in the future, as per: https://wiki.gnome.org/Design/OS/LockUnlockLogin
Comment 6 Florian Müllner 2019-01-24 20:07:43 UTC 
There is no existing setting to disable the screen shield. But then from the description, I'm not sure that such a setting would actually be right; there are two cases that trigger the screen shield:

 1. when the screen is locked

   This can either be a user action (super+l, the system menu), which can be disabled with
   gsettings set org.gnome.desktop.lockdown disable-lock-screen true

   Or it can be the automatic screen lock on idle, which can be disabled with
   gsettings set org.gnome.desktop.screensaver lock-enabled false

 2. When the session becomes idle, after fading the screen

   This is where the screen shield cannot be turned off. However it *is* possible to 
   prevent the session from becoming idle, so the screen doesn't fade and the shield 
   isn't activated:
   gnome-session-inhibit --inhibit-only

   If that is an acceptable solution, it can be automated by placing a .desktop file
   in /etc/xdg/autostart with something like:
 
   [Desktop Entry]
   Type=Application
   Name=Inhibit session idle
   NoDispay=True
   Exec=gnome-session-inhibit --inhibit-only
Comment 7 Tomas Pelka 2019-02-26 10:01:45 UTC 
(In reply to Florian Müllner from comment #6)
> There is no existing setting to disable the screen shield. But then from the
> description, I'm not sure that such a setting would actually be right; there
> are two cases that trigger the screen shield:
> 
>  1. when the screen is locked
> 
>    This can either be a user action (super+l, the system menu), which can be
> disabled with
>    gsettings set org.gnome.desktop.lockdown disable-lock-screen true
> 
>    Or it can be the automatic screen lock on idle, which can be disabled with
>    gsettings set org.gnome.desktop.screensaver lock-enabled false
> 
>  2. When the session becomes idle, after fading the screen
> 
>    This is where the screen shield cannot be turned off. However it *is*
> possible to 
>    prevent the session from becoming idle, so the screen doesn't fade and
> the shield 
>    isn't activated:
>    gnome-session-inhibit --inhibit-only
> 
>    If that is an acceptable solution, it can be automated by placing a
> .desktop file
>    in /etc/xdg/autostart with something like:
>  
>    [Desktop Entry]
>    Type=Application
>    Name=Inhibit session idle
>    NoDispay=True
>    Exec=gnome-session-inhibit --inhibit-only

Andrew do you know whether this workaround was sufficient to resolve this issue?

Thanks
-Tom
Comment 8 afox@redhat.com 2019-03-01 17:05:44 UTC 
Hi Tom, 

I just pinged the customer, and they say that this does not resolve the issue.
They still see the screen shield, even with this workaround in place. 

Do you have any other suggestions? 

Thanks,

Andy.
Comment 9 Tomas Pelka 2019-03-01 20:56:50 UTC 
I don't sorry, back to Florian.
Comment 10 Florian Müllner 2019-03-11 16:28:12 UTC 
(In reply to afox from comment #8)
> They still see the screen shield, even with this workaround in place. 

When exactly are they seeing the screen shield? After leaving the system idle for some time, or after a particular user action?
Comment 11 afox@redhat.com 2019-03-22 17:39:28 UTC 
Hi Florian, 

Have got some more background on this issue now from the customer. 

They are currently rolling out RHEL desktops to users running as VMs. 
These particular users have Windows desktops and connect to the RHEL VM using VMWare Horizon Client. 

The screen shield is automatically coming down whenever the users disconnect from the VM (by closing Horizon Client). 
When they reconnect, the screen shield is in place. 

Could it be that we're seeing a different event in this case which is triggering it? 
Is there a way to tell what that is, and prevent it? 

Thanks,

Andy.
Comment 12 Florian Müllner 2019-04-11 15:26:18 UTC 
(In reply to afox from comment #11)

> Could it be that we're seeing a different event in this case which is
> triggering it? 
> Is there a way to tell what that is, and prevent it? 

Sorry, I meant to comment on this earlier:
I still don't know what exactly is going on, the shield should not come up unless the screen is locked (automatically or by the user) or the system becomes idle.

But as this is urgent, we decided to instead include the "disable-screenshield" extension, which allows for explicitly disabling the screenshield rather than trying to eliminate its triggers.

The extension is included in the 3.28.1-7 build from March 26.
Comment 18 errata-xmlrpc 2019-08-06 12:37:45 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2044
Note You need to log in before you can comment on or make changes to this bug.