Bug 1643501

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.

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

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

(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

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.

I don't sorry, back to Florian.

(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?

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.

(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.

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