Oh, forgot: Version is 3.0.2 on Debian.

Could you possibly hack the session a bit to remove some components, so we know which one is creating this? I doubt this is gnome-session (I don't think gnome-session changes the cursor anymore).

Thanks for the hint about gnome-session not touching the cursor, a quick log-out and log-in, which fixed the problem, indicates that this has to do with gdm3 autologin, i.e. gdm3 setting the busy wait cursor, but not removing it unless the greeter has been shown.

It is still the question whether this is intentional, and gnome-session should reset the cursor, or whether gdm should clean up.

(I yet have to verify this using some plain xterm session or something, but right now.)

Indeed, if I use gdm3 auto-login into a plain “xterm” session, I get the GDK_BUSY cursor. If I start the session directly with "startx xterm", I don’t. So it seems that gdm3 is somehow the culprit. I’m attaching a gdm debug log.

But:
$ fgrep -r GDK_WATCH . 
./utils/gdm-screenshot.c:        cursor = gdk_cursor_new (GDK_WATCH);
./gui/simple-greeter/gdm-language-chooser-dialog.c:        cursor =  gdk_cursor_new (GDK_WATCH);
./gui/simple-greeter/gdm-greeter-login-window.c:        cursor = gdk_cursor_new (GDK_WATCH);

and with auto-login, according to the log file, neither greeter nor chooser get started. What else could be setting the cursor?

Ah, I think I found the code, in ./daemon/gdm-simple-slave.c:
static void
setup_server (GdmSimpleSlave *slave)
{
        /* Put cursor out of the way on first head */
        gdm_slave_set_initial_cursor_position (GDM_SLAVE (slave));

        /* Set the busy cursor */
        gdm_slave_set_busy_cursor (GDM_SLAVE (slave));
}

This is called in idle_connect_to_display in:
                setup_server (slave);

                delay = 0;
                enabled = FALSE;
                gdm_slave_get_timed_login_details (GDM_SLAVE (slave), &enabled, NULL, &delay);
                if (! enabled || delay > 0) {
                        start_greeter (slave);
                        create_new_session (slave);
                } else {
                        /* Run the init script. gdmslave suspends until script has terminated */
                        gdm_slave_run_script (GDM_SLAVE (slave), GDMCONFDIR "/Init", GDM_USERNAME);
                        reset_session (slave);
                }

So maybe  setup_server needs to be moved before start_greeter. Alternatively, (since setup_server also positions the mouse), the cursor should be re-set before running the /Init script.

I’ll testt the “easy” solution now...

Created attachment 201400 [details]
GDM Log of an auto-login session

Created attachment 201401 [details] [review]
Simple fix

Indeed, that is the problem. The simple slave sets the cursor to WAIT, which is fine if it is followed by the greeter, which will reset the cursor. But if auto-login is used, then this does not happen.

The attached fix avoids setting the cursor if the auto-login route is taken, but leaves the cursor in the middle of the screen. Better fixes would be 
 * Splitting setup_server to always position the cursor, but not set it to WAIT if auto-login is done in idle_connect_to_display().
 * Identifying the right spot in the auto-login patch to reset the cursor.

The fact that the slave class provides gdm_slave_set_busy_cursor(), but no gdm_slave_reset_cursor() indicates some mismatch here.

In any case, this should be reassigned to gdm3.

Hmm, I just noticed that now I get the 80ies X cursor instead. So I guess the proper solution is to set the reset the curser somewhere in static-salve the same way as it wold be done in the greeter.

Another note: If a session is started from scratch (e.g. via startx) it is expected to set the cursor anyways, as otherwise the X cursor would stay. By that argument, one could claim that gdm has every right to leave the cursor in some undefined condition, including GDK_WAIT. If you follow that line of argument feel to close the bug.

I have fixed it for my situation (a window manager that does not set the root cursor) using
echo xsetroot -xcf /usr/share/icons/Adwaita/cursors/left_ptr 16 >> .gnomerc

It seems that metacity would set the cursor anyways (not tested, but grep’ed through the source code), so the regular gnome fallback session is not affected by this bug.

Thanks for the investigative work on this bug.  I think the logic in comment 9 is probably right.  As it stands, we really want autologin to set a busy cursor and have the window manager set it to a non-busy cursor, since it's appropriate to have a busy cursor while things are loading.

Though, see bug 652066 for some discussion about alternates to cursors for busy notification.

Thanks for responding, I agree that it makes sense to expect the WM to set the cursor. But in that case, shouldn’t gdm set the cursor back to busy even after a non-auto-login, so that it behaves consistently?

indeed.