0

On an AlmaLinux 8.10 system with GNOME Version 3.32.2 I have left the Screen Lock configuration at the default of locking the desktop session after being idle for 5 minutes.

If I am actively using a desktop session, but only providing keyboard input, after 5 minutes of keyboard activity without needing to move the mouse then the screen locks. Therefore, it appears that the detection of if the desktop session being idle only monitors the mouse input and not the keyboard input.

The keyboard and mouse are both USB, and are connected via a KVM switch.

Looking at the settings can't find anything which explains the the definition of the desktop session being idle only monitors mouse activity.

Searching found the answer which shows the gsettings command to obtain Screen Lock related settings, which on the affected system are:

$ gsettings list-recursively org.gnome.desktop.screensaver
org.gnome.desktop.screensaver picture-opacity 100
org.gnome.desktop.screensaver logout-enabled false
org.gnome.desktop.screensaver lock-enabled true
org.gnome.desktop.screensaver logout-delay uint32 7200
org.gnome.desktop.screensaver embedded-keyboard-enabled false
org.gnome.desktop.screensaver primary-color '#023c88'
org.gnome.desktop.screensaver idle-activation-enabled true
org.gnome.desktop.screensaver secondary-color '#5789ca'
org.gnome.desktop.screensaver logout-command ''
org.gnome.desktop.screensaver color-shading-type 'solid'
org.gnome.desktop.screensaver embedded-keyboard-command ''
org.gnome.desktop.screensaver picture-options 'scaled'
org.gnome.desktop.screensaver lock-delay uint32 0
org.gnome.desktop.screensaver show-full-name-in-top-bar true
org.gnome.desktop.screensaver picture-uri 'file:///usr/share/backgrounds/Alma-abstract-dark.xml'
org.gnome.desktop.screensaver status-message-enabled true
org.gnome.desktop.screensaver user-switch-enabled true

$ gsettings list-recursively org.gnome.desktop.session
org.gnome.desktop.session session-name 'gnome'
org.gnome.desktop.session idle-delay uint32 300

The computer is a desktop, rather than a laptop, so is always on mains power. Therefore, the org.gnome.settings-daemon.plugins.power settings shouldn't be relevant but for completeness they are:

$ gsettings list-recursively org.gnome.settings-daemon.plugins.power
org.gnome.settings-daemon.plugins.power power-button-action 'suspend'
org.gnome.settings-daemon.plugins.power idle-dim true
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
org.gnome.settings-daemon.plugins.power sleep-inactive-battery-timeout 1800
org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type 'nothing'
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 3600
org.gnome.settings-daemon.plugins.power ambient-enabled true
org.gnome.settings-daemon.plugins.power idle-brightness 30

The question is if the Screen Lock activating while the keyboard is being used, but not the mouse within the idle-delay:

  1. Due to some configuration setting which I haven't found.
  2. Working by design.
  3. A bug.
Chester Gillon
  • 1,573

1 Answers1

0

The issue in the question was still happening on the same system about 1 year later. Updates had been applied to the system as were made available, e.g. the Kernel and other packages, but:

  • The base operating system was still AlmaLinux 8.10.
  • GNOME was still version Version 3.32.2.

When the issue was found was using Wayland (the default).

At the logon screen, used the "cog" option a number of times to change the display server used:

  1. If select X11 then the lock screen doesn't activate when only using the keyboard. Confirmed that if stop using the keyboard, then after ~5 minutes the lock screen still activated. This, to me, is the desired behaviour.
  2. If select Wayland the lock screen does activate when only using the keyboard.

This suggests there could be a bug (or design limitation) that when Wayland is used the idle timer for the screen lock only monitors the mouse and not the keyboard.

Posting this answer since gives a work around of using X11, even though the root cause isn't yet explained.

Chester Gillon
  • 1,573