Confirmed behavior, the pointer sits just to the right, I assume this is the default X position.

Note that you don't need to click on GDM it just needs the mouse over it.

*** Bug 333658 has been marked as a duplicate of this bug. ***

From the distro bug:

"--- gdm-2.13.0.9/gui/greeter/greeter.c 2006-02-17 02:08:55.000000000 +0100
+++ gdm-2.13.0.9.xinerama/gui/greeter/greeter.c 2006-03-14 13:15:40.000000000 +0100
@@ -1344,7 +1347,7 @@
       /* Run the focus, note that this will work no matter what
        * since gdm_wm_init will set the display to the gdk one
        * if it fails */
- gdm_wm_focus_window (GDK_WINDOW_XWINDOW (window->window));
+ gdm_wm_focus_new_windows (TRUE);
     }

   if G_UNLIKELY (session_dir_whacked_out)

is a patch which fixes this problem for me and doesn't appear to have
other effects.

The reason why gdm_wm_focus_window can't be used is the window is not
mapped yet, so trying to focus it will fail. I'm unsure why it's not
mapped, though."

The problem with using gdm_wm_focus_new_windows is that this turns on the focus_new_windows flag and this never gets turned off.  You'll notice this is normally only used when a pop-up is going to be displayed.  Actually this seems sort of broken to me.  Do we want gdmlogin and gdmgreeter to always just make focus go to the last window displayed?  If so we could perhaps rip out all the gdm_wm_focus_window calls and just put a single gdm_wm_focus_new_window (TRUE) call in there.

But, this does seem strange.  If you have a bit of time, I would appreciate if you could look into this a bit furter so we could understand what is going on here.  Since these calls are after the gtk_widget_show_all and gtk_widget_show_now calls, I'd expect that the window would be mapped.  Also, I notice that gui/gdmlogin.c has pretty much the same gdm_wm calls, but people only seem to complain about this problem with gdmgreeter.  Do you notice the same problem in gdmlogin?  I'm assuming you can also debug the gdmwm code and see if the window is also unmapped there when the gdm_wm_focus_window call is made?  If we see the problem in both programs, then I'd be happier fixing the code as you suggest in your patch.

When you say the window is unmapped do you mean it isn't drawn to the screen or the gdmwm code doesn't seem to know about the window yet?  Note that gdm_wm_init calls add_all_current_windows() and this should notice the window, and add it to the list.  If this is failing, then perhaps there is a race condition where the window's MapNotify event is happening after the call to gdm_wm_focus_window.  You could probably test this by putting a breakpoint in the event_process function and see if the code has already passed the gdm_wm_focus_window function by this time.  If this is the problem, I'd lean towards just setting focus_new_windows to TRUE all the time, because I'm not sure how we could better manage the race condition.  It would seem weird to make gdmgreeter wait for the MapWindow call before callng gdm_wm_focus_window.

*** Bug 334729 has been marked as a duplicate of this bug. ***

gdmlogin has the exact same problem; I guess the reason why you don't see bug reports about it is that nobody uses it any more. :-)

As for the unmapped window, yes, it's in gdm_wm_focus_window:

        XGetWindowAttributes (wm_disp, window, &attribs);
        if (attribs.map_state == IsUnmapped) {
                trap_pop ();
                return;
        }

this evaluates to true and the function just short-circuits and returns.

Later, in greeter.c(main) we call gdm_wm_restore_wm_order which causes at least two events to be emitted: ConfigureRequest, then a MapRequest, which then causes the gdmwm to call XMapWindow.

I agree that just setting focus_new_windows to TRUE would be sane.

*** Bug 339383 has been marked as a duplicate of this bug. ***

Have you given this any more thought?  I can't see any downsides to just unconditionally focusing new windows, can you? 

I'm sorry I have been so slow to accept this patch.  I recognize that there is a problem here, but I am not confident this is the right solution.  I especially worry about configurations where people use BackgroundProgram to launch additional applications that have GUI's.  What if the GUI has dialog's, etc. that launch additional windows.  I'd be more comfortable with accepting this patch if someone were able to do a little more testing with it.

Perhaps a less invasive fix would be better, such as fixing the code so it puts the cursor in the right place in Xinerama mode?  Or are there other problems that changing the code to always focus new windows fixes?

I also notice, by the way, that gdmsetup seems to lose focus when it restarts the greeter.  Another annoying problem with the window focus code.

Note that I'm not actually using Xinerama, I'm using nvidia's TwinView.  (Gdm apparently detects this as something close to Xinerama because it restricts itself to one of my (physical) displays.

I think X is responsible for the initial cursor position since it appears in the middle of one of the (physical) screens if I use Xinerama instead of TwinView.  Having gdm move the mouse pointer about when starting up would be considered bad, IMO.

I could always test with BackgroundProgram and see what the damage would be.

Another option would be to tag the gdmgreeter window with some atom and special-case that in gdmwm to always focus it when it's mapped.  It'd a somewhat-ugly hack, but should work.

Yes, if you were willing to test and make sure it works with BackgroundProgram, then that would make me much more comfortable with the patch.

Why would it be bad for GDM to move the mouse pointer to the center of its dialog on startup?  This seems reasonable to me.

I'm not sure that always focusing gdmgreeter when mapped would be good.  When gdmsetup is running, it is supposed to have focus instead.  Also, how would users interact with BackgroundProgarms with GUI's if the greeter always had focus?

What if gdm were to read the pointer's position when it starts and open the greeter on the same monitor instead of monitor 0 or whatever it's doing now?

Yes, this would be acceptable as well.

(In reply to comment #12)
> What if gdm were to read the pointer's position when it starts and open the
> greeter on the same monitor instead of monitor 0 or whatever it's doing now?

I am using TwinView (so the mouse is initially positioned to the left corner of the second screen), and i have a TV connected to the second head. The TV's not even turned on all the time. That proposition wouldn't work in my configuration.

It's probably safe to assume the monitor 0 is the primary one.

*** Bug 347733 has been marked as a duplicate of this bug. ***

Created attachment 70166 [details] [review]
center cursor on main head

Does this patch fix the problem? I wrote and committed it to rawhide a couple of weeks ago, but I haven't actually had an opportunity to test it yet.

Ray, why don't you commit this fix to the 2.15 branch so it can go into the 2.16 release.  I'd like to have this fixed, if possible before then.

Sure.  It'd be nice if someone with a multihead setup confirmed that it fixes the problem though...

Let's leave this open a bit longer to see if we can get verification.  I suspect that including the patch in a release will help get a response to verify it fixes the problem.  Reviewing the code, it looks like it should work to me.

This patch works around the problem for me, with the cosmetic problem that my mouse pointer is moved from wherever I have positioned it in the time between X having started and gdm starting.

This sounds great.. I would love to see it in edgy eft this october.  Will it be there?

The cosmetic problem doesn't sound too bad to me.  I think we should go with this solution, at least until someone else comes up with a better patch that fixes the focus problem without needing to move the mouse pointer.

*** Bug 359387 has been marked as a duplicate of this bug. ***