Same thing for me. It seems like the login screen is appearing on whichever monitor contains the mouse pointer. In my case (at bootup) the mouse pointer seems to be automatically placed one or a few pixels right of centre, resulting in a login screen on my secondary monitor. 

If the primary screen could be identified and used instead that would be way better. :)

Not sure if this is relevant to this problem, but I've written a patch for gtk+ to add support for querying the primary monitor from xrandr.  This could be useful to fix this.

https://bugzilla.gnome.org/show_bug.cgi?id=601712

This seems to happen more often in GDM 3 than previously. The login screen will always be on the screen where the cursor is as GDM loads, amd at boot that now always seems to be the wrong screen.

Is there actually a use case that requires GDM to display on anything other than the primary screen?

we fixed this a while ago:

http://git.gnome.org/browse/gdm/commit/?id=90ab791544d676629800e80fcf7a28a628f94e94

As far as I understand that patch, it seems that what's happening now is that GDM is intentionally putting the cursor on the second screen, and so the greeter will always be there also.

I would guess that this is because nvidia presents the two screens together, and so the "*x = crtc_info->x + .9 * crtc_info->width;" means mostly to the right, so somewhere on the second screen.

Unless there is some way to identify where each physical screen lives, would it be possible to simply aim the cursor somewhere else (top left-ish?), assuming that second screen to the right is actually the more common choice.

The old GDM 2.20 supported configuration options where the sysadmin could control things like the position of the login GUI.  If the nvidia driver makes it too difficult for GDM to just "do the right thing" by default, then perhaps we should add configuration options to the GUI to address this sort of limitation?

crtc_info is the info for a particular monitor, not the aggregrate of them all.

It's looking for the "primary" monitor (as configured) and putting the cursor in the lower right of that monitor.

I just started experiencing the problem and I don't think this bug should be marked as RESOLVED. I suspect the nVidia driver is reporting both monitors as one and hence crtc_info contains the info about aggregate of both.

I used to have two screens: main monitor 1600x1200 and an LCD TV 1366x768. The LCD was on the right and the "center of both" was somewhere on the main monitor. The login screen was always appearing in the expected place (main monitor).

Yesterday I installed my new TV which is 1920x1080. This has moved the "center of both" to the secondary screen (TV). Now the login screen always starts on the TV unless I manage to move the cursor to the left before it pops up.

It's very annoying for my wife. I don't care that much - I don't need to see the login screen to enter my credentials as I remember which keyboard keys to press. But other users have a problem (since they're not the first in the user list).

I really think it would be beneficial, if the users were given an option to override the default behavior and to put the login window wherever they want. I don't expect you can cover all configuration cases (one, two, three, four, more monitors, on the left, right, top, bottom, across...) with simple formulas. Please give us an option to choose manually.

Reopening.

I've got the same problem here with GDM 3, Nvidia 7600 GT, TFT monitor + CRT TV; with TV right of monitor but most time turned off.
It would be really nice to have an option to place the login window wherever the user wants it in X/Y coordinates. In times where more and more users have more than one screen this should be standard for almost every application, but sadly is not.

I believe you can drag the window around with the alt key.  it's not persistent though.

So what should people with laptops and docking stations do? I'd like to be able to leave the lid closed when the laptop is docked. In the GDM 2.x times this was possible, but now the greeter is always shown on the laptop's display *even*though* the lid is closed and the display is turned of.

I'm using GDM 3.0.4 on Fedora 15.

I found a workaround. Install xwit and add the line
xwit -root -warp XPOS YPOS
to /etc/gdm/Init/Default (just befor the exit 0 line)
XPOS and YPOS should be replaced with values from the screen where you want the login window to appear. xwit moves the mouse pointer to that position.
But this workaround only helps if you always want to have the login window always on the same screen. 
If for some reason you want it to appear on another screen sometimes, you have to move the mouse to the active screen and hit ESCAPE. No need to drag the window with the ALT key.

Christoph, if we're marking the laptop display as "primary" when the lid is closed that's probably a bug in gnome-settings-daemon and/or X that needs to be investigated.

So how can I find out if g-s-d marks it primary?

The greeter appears even on the laptop screen if the lid is closed and the display is turned of. Once I open it the display gets cloned to both screens but uses the lower resolution of the internal screen.

Ray, any idea how to debug gnome-settings-daemon?

oh federico is investigating it now, let me find the bug

bug 663126

Bug 663126 is about problems with docking stations but it turns out my problem even appears when my laptop is not docked and has a display attached directly to vga-out. The greeter is *always* displayed on the internal display, even if is closed and regardless of the laptop being docked or not or on AC or not.

Yea, I'm pretty sure we don't try to differentiate between those two cases (anymore)

But that would mean that the whole testing and providing fixes for docking stations is completely useless and g-s-d's handling of external displays is completely broken.

Not sure I follow. Can you explain what you mean  in greater detail?

The relevant code is in upowerd at upower/src/linux/up-dock.c up_dock_refresh(),
paraphrased here:

count = 0;

/* the metric we're using here is that a machine is docked when there is more than one connected output */
devices = g_udev_client_query_by_subsystem (dock->priv->gudev_client), "drm");

for each device in devices:
    if (device status file reads "connected")
        count++;

if (count > 1)
   up_daemon_set_is_locked (daemon, TRUE);

Sorry if I was unclear or my comment sounded like a rant. That was not my intention.

Not that I read the code I understand that the laptop is considered docked if there is more then one display connected. But why is a display seen as connected if it is closed? I guess this is a bug in upowerd.

But what about setting the external display as primary. Is this an assumption that gdm should could make in order to display the greeter there?

> Now that I read the code I understand that the laptop is considered docked if
> there is more then one display connected. But why is a display seen as
> connected if it is closed?
I believe the kernel used to mark displays as inactive (but still connected) when the lid was closed, but the code was causing problems with a number of machines so it was removed out right.

There's a discussion about it here:
http://people.freedesktop.org/~halfline/the-troubling-tale-of-fibbing-laptop-lids.txt

So now the idea is to handle it all in gnome-settings-daemon.  It presumably will also cause problems with a set of laptops, but hopefully we can fix those as they crop up.
 
> But what about setting the external display as primary. Is this an assumption
> that gdm should could make in order to display the greeter there?
GDM does make sure it uses the primary display for its login window.

From the other bug it looks like you're going to give the g-s-d patches a try. Let me know if they fix things for you.

Which patches exactly? YOu mean http://git.gnome.org/browse/gdm/commit/?id=90ab791544d676629800e80fcf7a28a628f94e94 ?

That change was in 3.0 already and meanwhile I am using gdm-3.2.1.1-14.fc17.x86_64 - but still the greeter is displayed on the closed lid.

yea that's the gdm side.  Do you have federico's changes in gnome-settings-daemon?

I think so. They were merged into master on 2012-01-11, this means just before g-s-d 3.3.4. I am running gnome-settings-daemon-3.3.92-1.fc17.x86_64.

okay so the problem is we look for the primary monitor before gnome-settings-daemon runs.  We should watch for the primary to change and then move the chooser I guess.

This is happening to me in 3.8.1. It worked correctly in 3.6, however.

i think this is fixed these days now that the greeter is maintained by gnome-shell.

It just does:

        this.actor.add_constraint(new Layout.MonitorConstraint({ primary: true }));•