GNOME Bugzilla – Bug 547865
Mouse cursor should be hidden before desktop fades to screensaver
Last modified: 2021-07-05 14:27:43 UTC
This feature request has been added by an user of Ubuntu on launchpad: At present, the desktop fades to black, then the screensaver comes on. But during that fade, the mouse cursor is still visible onscreen -- creating a white distraction as the screen is fading. It shouldn't be difficult to hide the cursor at the beginning of the fade, therefore giving the impression that the desktop is very smoothly transitioning to the screensaver.
Sure. Sounds ok. Have a patch?
The screen lock is now implemented directly in gnome-shell, not in gnome-screensaver (as it was with older version of GNOME 3 and GNOME 2.x). gnome-shell handles the fade, so reassigning there.
The screen lock toggles the visibility of the cursor as soon as the shield falls, and before it starts the fade to black animation. The cursor is shown again as soon as an event arrives. I think this bug should be resolved, unless there are other issues lying around.
(In reply to Emmanuele Bassi (:ebassi) from comment #3) > The screen lock toggles the visibility of the cursor as soon as the shield > falls, and before it starts the fade to black animation. The cursor is shown > again as soon as an event arrives. > > I think this bug should be resolved, unless there are other issues lying > around. The problem isn't the shield, the problem is before, when the screen starts fading. The cursor is still visible when the fading starts, and it doesn't fade with the rest of the UI, as it's above the fade screen. Either it should be hidden when the fade starts, or it should be placed underneath the fade box (which I don't even know if it's technically possible).
(In reply to Bastien Nocera from comment #4) > (In reply to Emmanuele Bassi (:ebassi) from comment #3) > > The screen lock toggles the visibility of the cursor as soon as the shield > > falls, and before it starts the fade to black animation. The cursor is shown > > again as soon as an event arrives. > > > > I think this bug should be resolved, unless there are other issues lying > > around. > > The problem isn't the shield, the problem is before, when the screen starts > fading. The cursor is still visible when the fading starts, and it doesn't > fade with the rest of the UI, as it's above the fade screen. I think this is where I lost the bug: if I lock the session, the shield comes down, the cursor disappears, and then the fading starts. I understand now that the bug describes what happens when the screen locks itself, i.e. it's been idle for a while. I assume that we should be able to hide the cursor as soon as the system is notified of an idle state and before we start the fade out animation, since we already have a case where we do that. > Either it should be hidden when the fade starts, or it should be placed > underneath the fade box (which I don't even know if it's technically > possible). Under X that's really not possible, since the cursor is managed by the server; I guess we could do something like this in Wayland, though.
It's not. The cursor is on a separate KMS plane than the shell.
(In reply to Emmanuele Bassi (:ebassi) from comment #5) > I assume that we should be able to hide the cursor as soon as the system is > notified of an idle state and before we start the fade out animation, since > we already have a case where we do that. As Ray noticed on IRC, we could have the cursor hide itself after any inactivity period, and that would take care of this bug as well. Since the shell is responsible for handling the cursor state and the idle tracking, these days, the reliability of that operation should be better than it used to be.
(In reply to Jasper St. Pierre from comment #6) > It's not. The cursor is on a separate KMS plane than the shell. Aaw. Oh, well.
of course we could also hide the cursor right away and put a transient actor on the stage where the mouse location is. (in the same vein as how we hide actors and put transient clones on screen sometimes)
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.