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 688757 - Hide the cursor until mutter takes over
Hide the cursor until mutter takes over
Status: RESOLVED OBSOLETE
Product: gnome-session
Classification: Core
Component: gnome-session
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Session Maintainers
Session Maintainers
Depends on: 688499
Blocks: 687791
 
 
Reported: 2012-11-20 22:06 UTC by Bastien Nocera
Modified: 2021-06-14 18:21 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bastien Nocera 2012-11-20 22:06:55 UTC
To implement bug 687791 and be sure that the cursor isn't visible on startup, or with an application being launched on startup, we need to make sure the cursor isn't shown before gnome-settings-daemon takes over policy duties.

This means that gnome-session should hide the cursor itself until gnome-settings-daemon is ready to handle the cursor.
Comment 1 Colin Walters 2012-11-20 22:57:18 UTC
So this is going to happen inside the gdm greeter session's invocation of gnome-session; but it seems to me that this is just pushing the problem slightly earlier; we basically need to boot the X server with the cursor hidden by default, right?  Something like how gdm passes -background none, right?
Comment 2 Bastien Nocera 2012-11-21 08:59:44 UTC
Xorg already does that.

The cursor will stay hidden until XDefineCursor() is called on the root window. This is what mutter does on startup, so we need to completely hide the cursor using XFixes before that happens.
Comment 3 Colin Walters 2012-11-21 10:46:01 UTC
Ah ok, so this is a gnome-settings-daemon/gnome-shell race condition on login.  

Makes sense then I guess.  It sounds like though given the X dependency a patch might conflict with Matthias' outstanding branch: http://git.gnome.org/browse/gnome-session/log/?h=wip/cleanups
Comment 4 Bastien Nocera 2012-11-21 10:56:21 UTC
Maybe a helper would do, but we need it running before anything else, and wait for g-s-d to show up.
Comment 5 Ray Strode [halfline] 2012-11-29 23:02:26 UTC
why don't we just remove the XDefineCursor call from mutter?
Comment 6 Bastien Nocera 2012-11-29 23:16:08 UTC
(In reply to comment #5)
> why don't we just remove the XDefineCursor call from mutter?

Because it would just delay the problem until an application is started, so you'd end up with a race.

See bug 688228.
Comment 7 Matthias Clasen 2012-11-29 23:54:16 UTC
(In reply to comment #3)
> Ah ok, so this is a gnome-settings-daemon/gnome-shell race condition on login.  
>

There's no race condition - gsd completes its startup in an earlier phase of session startup, before gnome-shell is ever started
Comment 8 Ray Strode [halfline] 2012-12-03 15:18:38 UTC
Assuming things work without this patch, I'm probably going to close this bug.  If things don't work without this patch, then we can push it, but I'm curious why they don't work.
Comment 9 Bastien Nocera 2012-12-14 16:31:40 UTC
I'm not certain this is needed in gnome-session, but there's still a bug in transitioning from gdm to the user's session. The cursor appears briefly in the top left of the screen, and I don't know what's setting it.

I'll try to make gnome-settings-daemon call the cursor code even earlier if I can (it used to be in an idle, now it's called sync when the plugins are initialised).
Comment 10 Ray Strode [halfline] 2012-12-14 20:17:46 UTC
I wonder if it's this code:

•
void•
gdm_slave_set_initial_cursor_position (GdmSlave *slave)•
{•
        if (slave->priv->server_display != NULL) {•
                int x, y;•
•
                determine_initial_cursor_position (slave, &x, &y);•
                XWarpPointer(slave->priv->server_display,•
                             None,•
                             DefaultRootWindow (slave->priv->server_display),•
                             0, 0,•
                             0, 0,•
                             x, y);•
        }•
}•
•
Comment 11 Bastien Nocera 2012-12-14 21:01:24 UTC
When does that code run?

The problem happens between me pressing "Enter" after typing my password, and just before the g-s-d code from the user session kicks in (I reckon, as the cursor hides then).
Comment 12 Bastien Nocera 2012-12-17 09:22:23 UTC
Might be https://bugzilla.freedesktop.org/show_bug.cgi?id=58398
Comment 13 Bastien Nocera 2012-12-18 08:01:49 UTC
Turns out there's nothing to handle the transition between gdm and the user session.

With the above patch for X.org, g-s-d master, gdm with the "no set root cursor" patch, and a stock mutter, and no mouse usage, the cursor will show up between the gdm and the user session in the top-left corner.

With a patched mutter, the cursor will be hidden.

Of course, patching mutter isn't good enough, as using the mouse in gdm, and then switching to using the touchscreen should keep the cursor hidden during the transition.

Is there anything we can do in gdm to make this work?
Comment 14 Owen Taylor 2012-12-18 16:40:50 UTC
(In reply to comment #13)
> Turns out there's nothing to handle the transition between gdm and the user
> session.
> 
> With the above patch for X.org, g-s-d master, gdm with the "no set root cursor"
> patch, and a stock mutter, and no mouse usage, the cursor will show up between
> the gdm and the user session in the top-left corner.
> 
> With a patched mutter, the cursor will be hidden.

Do you have any explanation for the behavior you've described here? It's hard to propose a way forward without understanding what is going on currently, and I don't. I assume that the X server is being recycled during the transition? Does that return things to the state where the initial cursor is empty? At that point, how is gdm relevant?
Comment 15 Bastien Nocera 2012-12-18 16:50:25 UTC
(In reply to comment #14)
<snip>
> Do you have any explanation for the behavior you've described here? It's hard
> to propose a way forward without understanding what is going on currently, and
> I don't. I assume that the X server is being recycled during the transition?
> Does that return things to the state where the initial cursor is empty? At that
> point, how is gdm relevant?

The explanation is very simple. Between the gdm's gnome-settings-daemon getting killed and the session's g-s-d starting, there's a gap. That's when the cursor is visible.

The X server is the same one between gdm and the session, so we don't get to reset the counter. I have no idea what could survive into the session to handle this transition.
Comment 16 Owen Taylor 2012-12-28 22:08:21 UTC
Can you make gdm unset the root cursor image before starting the new session? (It sounds like the reason that the patched Mutter is "fixing" this problem is that it never sets the root cursor image *in the GDM session* because there happens to be no startup notification in the GDM session.)
Comment 17 Bastien Nocera 2013-01-02 15:33:43 UTC
(In reply to comment #16)
> Can you make gdm unset the root cursor image before starting the new session?

It cannot. Once the cursor is set, the only way to hide it is using the XFixesHideCursor() function, which means something needs to bridge the gap between the gdm chooser exiting and gnome-session/gnome-settings-daemon starting in the session.

> (It sounds like the reason that the patched Mutter is "fixing" this problem is
> that it never sets the root cursor image *in the GDM session* because there
> happens to be no startup notification in the GDM session.)

That's exactly what happens.
Comment 18 Ray Strode [halfline] 2013-01-02 17:03:17 UTC
- The mutter that runs at the login screen shouldn't call XDefineCursor during startup
- The gnome-settings-daemon that runs at the login screen should show the cursor when the user moves the mouse.
- The gnome-settings-daemon that runs at the login screen should hide the cursor when the user stops moving the mouse.
- Nothing needs to run after the login screen exits before the user session starts. The mouse should be hidden from the previous hide cursor call
- The mutter that runs in the user session shouldn't call XDefineCursor during startup
- The gnome-settings-daemon that runs in the user session should show the cursor when the user moves the mouse.
- The gnome-settings-daemon that runs in the user session should hide the cursor when the user stops moving the mouse.

basically, the mouse cursor is a software feature for people using mouse hardware.  gnome-settings-daemon handles input devices, and so knows when to show and hide the cursor, since it knows when a user has a mouse.  It runs the show, everything else should stop mucking with the cursor.

Right? I think i'm missing the complication.
Comment 19 Ray Strode [halfline] 2013-01-02 20:29:18 UTC
I guess what mutter does is irrelevant, too.  gnome-settings-daemon just needs to run XFixesHideCursor() at startup. Then, run XFixesShowCursor() when the user moves the mouse.  When the user stops moving the mouse call XFixesHideCursor() again.
Comment 20 Owen Taylor 2013-01-03 13:43:46 UTC
(In reply to comment #17)
> (In reply to comment #16)
> > Can you make gdm unset the root cursor image before starting the new session?
> 
> It cannot. Once the cursor is set, the only way to hide it is using the
> XFixesHideCursor() function, which means something needs to bridge the gap
> between the gdm chooser exiting and gnome-session/gnome-settings-daemon
> starting in the session.

You can always hide the cursor by setting it to an empty cursor image - which is what the -nocursor option to X effectively does. The reason that the X fixes API exists, as I understand it, is to be able to temporarily hide the cursor without interfering with the image set for the cursor.
Comment 21 Owen Taylor 2013-01-03 13:50:15 UTC
(In reply to comment #18)
> - The mutter that runs at the login screen shouldn't call XDefineCursor during
> startup
> - The gnome-settings-daemon that runs at the login screen should show the
> cursor when the user moves the mouse.
> - The gnome-settings-daemon that runs at the login screen should hide the
> cursor when the user stops moving the mouse.
> - Nothing needs to run after the login screen exits before the user session
> starts. The mouse should be hidden from the previous hide cursor call
> - The mutter that runs in the user session shouldn't call XDefineCursor during
> startup
> - The gnome-settings-daemon that runs in the user session should show the
> cursor when the user moves the mouse.
> - The gnome-settings-daemon that runs in the user session should hide the
> cursor when the user stops moving the mouse.
> 
> basically, the mouse cursor is a software feature for people using mouse
> hardware.  gnome-settings-daemon handles input devices, and so knows when to
> show and hide the cursor, since it knows when a user has a mouse.  It runs the
> show, everything else should stop mucking with the cursor.
> 
> Right? I think i'm missing the complication.

I think you are missing the basic complication that the root cursor has an *image* - and someone has to be in charge of that image. Traditionally, that's the window manager. If we can't figure out how to manage visibility state of the cursor independently of the image, then we need to move the cursor image to g-s-d as well (without research, my memory is that the startup notification protocols would allow that) - but if we can keep the image control in the WM that seems easier. 

I do not want some solution that requires Mutter to not call XDefineCursor at some times and to call XDefineCursor at other times.
Comment 22 Bastien Nocera 2013-01-03 13:59:03 UTC
(In reply to comment #19)
> I guess what mutter does is irrelevant, too.  gnome-settings-daemon just needs
> to run XFixesHideCursor() at startup.

It already does.

> Then, run XFixesShowCursor() when the
> user moves the mouse.  When the user stops moving the mouse call
> XFixesHideCursor() again.

If the caller to XFixesHideCursor dies (eg. if the gdm g-s-d dies) then the cursor will be shown again. Otherwise you could end up with the cursor being invisible because of a single app.

(In reply to comment #20)
> (In reply to comment #17)
> > (In reply to comment #16)
> > > Can you make gdm unset the root cursor image before starting the new session?
> > 
> > It cannot. Once the cursor is set, the only way to hide it is using the
> > XFixesHideCursor() function, which means something needs to bridge the gap
> > between the gdm chooser exiting and gnome-session/gnome-settings-daemon
> > starting in the session.
> 
> You can always hide the cursor by setting it to an empty cursor image - which
> is what the -nocursor option to X effectively does. The reason that the X fixes
> API exists, as I understand it, is to be able to temporarily hide the cursor
> without interfering with the image set for the cursor.

I think that's probably the best way to do things. I would want to do that in gdm, when it transitions from gdm to the user session. Where would I plug that in?
Comment 23 Bastien Nocera 2013-01-03 14:05:42 UTC
(In reply to comment #21)
> (In reply to comment #18)
> > - The mutter that runs at the login screen shouldn't call XDefineCursor during
> > startup
> > - The gnome-settings-daemon that runs at the login screen should show the
> > cursor when the user moves the mouse.
> > - The gnome-settings-daemon that runs at the login screen should hide the
> > cursor when the user stops moving the mouse.
> > - Nothing needs to run after the login screen exits before the user session
> > starts. The mouse should be hidden from the previous hide cursor call
> > - The mutter that runs in the user session shouldn't call XDefineCursor during
> > startup
> > - The gnome-settings-daemon that runs in the user session should show the
> > cursor when the user moves the mouse.
> > - The gnome-settings-daemon that runs in the user session should hide the
> > cursor when the user stops moving the mouse.
> > 
> > basically, the mouse cursor is a software feature for people using mouse
> > hardware.  gnome-settings-daemon handles input devices, and so knows when to
> > show and hide the cursor, since it knows when a user has a mouse.  It runs the
> > show, everything else should stop mucking with the cursor.
> > 
> > Right? I think i'm missing the complication.
> 
> I think you are missing the basic complication that the root cursor has an
> *image* - and someone has to be in charge of that image. Traditionally, that's
> the window manager. If we can't figure out how to manage visibility state of
> the cursor independently of the image, then we need to move the cursor image to
> g-s-d as well (without research, my memory is that the startup notification
> protocols would allow that) - but if we can keep the image control in the WM
> that seems easier. 
> 
> I do not want some solution that requires Mutter to not call XDefineCursor at
> some times and to call XDefineCursor at other times.

I don't fancy moving startup-notification to g-s-d, there's enough things as it is in there. Given that g-s-d starts before mutter in both the gdm and user sessions, g-s-d can use XFixes to hide the cursor before mutter resets it. The only time where we don't have an app running is in the transition between the gdm and user session. If gdm sets an empty image as the cursor when logging us in, problem solved (though you might want gdm asking g-s-d whether to hide it, or telling g-s-d to hide it because it will be logging a user in...).
Comment 24 Ray Strode [halfline] 2013-01-03 21:41:17 UTC
(In reply to comment #22)
> If the caller to XFixesHideCursor dies (eg. if the gdm g-s-d dies) then the
> cursor will be shown again. Otherwise you could end up with the cursor being
> invisible because of a single app.
Ahhhhh, that's the bit I was missing. It's ref counted and tied to the display connection.

(In reply to comment #20)
> You can always hide the cursor by setting it to an empty cursor image 
Yea that seems like the easiest way to go.

(In reply to comment #23)
> If gdm sets an empty image as the cursor when logging us in, problem solved
> (though you might want gdm asking g-s-d whether to hide it,
> or telling g-s-d to hide it because it will be logging a user in...).
Could just do it in the cursor plugin at deactivation time instead of doing it from gdm.
Comment 25 Bastien Nocera 2013-01-03 22:55:09 UTC
(In reply to comment #24)
> (In reply to comment #23)
> > If gdm sets an empty image as the cursor when logging us in, problem solved
> > (though you might want gdm asking g-s-d whether to hide it,
> > or telling g-s-d to hide it because it will be logging a user in...).
> Could just do it in the cursor plugin at deactivation time instead of doing it
> from gdm.

The lifecycle of g-s-d isn't tied to that of the session unfortunately. I don't even know how it gets killed by gdm/gnome-session. This means that replacing an existing g-s-d (to debug for example) could have some pretty nasty side effects, requiring gnome-shell/mutter to restart to reset the cursor.
Comment 26 Nicolas Maia 2016-04-13 13:35:59 UTC
Bug #764994 may be related to this.
Comment 27 André Klapper 2021-06-14 18:21:36 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 of gnome-session, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-session/-/issues/

Thank you for your understanding and your help.