Between Fedora 11 and Fedora 12, the default X server mode for multiple display situations was changed from clone - display the same output on all connected displays - to span - spread the output across all connected displays.

firstboot does not cope well with this. It's run in a bare X server so there's no window manager to help deal with the multihead wrinkles, and firstboot doesn't do anything about them itself. this is problematic.

in the very best case, you get a usable firstboot spanned across two displays - see jlaska's screenshot: http://jlaska.fedorapeople.org/Screenshot-firstboot.png

this would look a bit weird to most people, but it's perfectly usable. unfortunately, that's only the best case. so far, we've come across two different much more problematic cases. on my system, here's what firstboot looks like with two 1680x1050 monitors attached:

http://www.happyassassin.net/extras/firstboot_dualhead_borkage.jpg

I think something is confused about the physical layout of the monitors, so the 3360x1050 firstboot screen - is starting at 1680x0 rather than 0x0, with the whole right hand half being inaccessible. Note that the right hand half includes the buttons you need to use to get through the wizard, which makes it impossible to get through unless you know the button layout and can use tab/enter, which obviously most people wouldn't. They'd be stuck looking at it, going 'huh?'

The second problematic case we've come across was a system with another bug - https://bugzilla.redhat.com/show_bug.cgi?id=529026 : it has a 'phantom' second display. X (well, the radeon driver) thinks a second display is connected, but really there isn't one. So, obviously, firstboot gets spanned across the two displays...the second of which doesn't exist. And, again, the right-hand half of the firstboot screen, with the buttons on it, isn't accessible. This was experienced by Robert Day, detailed in this test-list thread:

https://www.redhat.com/archives/fedora-test-list/2009-October/msg00235.html

I can think of at least one other likely problematic case: imagine what'd happen on a system with a primary display with a larger Y resolution than secondary display - e.g. one output at 1600x1200, a second at 1024x768. As the important buttons are at the bottom right-hand corner of the display, I suspect they'd get rendered into the dead space under the smaller right-hand screen - i.e. they'd be at something like 2500x, 1000y, which is actually not an area you can see with such a monitor configuration.

There may well be other problems that I haven't thought of. Basically, I don't think firstboot has been written in any way to expect to work in multi-head span configurations.

Recommendation: the simplest and safest fix I can think of is for firstboot to explicitly start its X server in clone mode rather than span mode. This would essentially revert to the same behaviour that's been used all along up until the X server configuration change, so it should be safe and a known quantity. The only question is whether it's possible / easy to actually do this. An X developer ought to be able to advise on this.

For now I'm setting this as blocking the Beta release, but that's a tentative assessment and to some extent depends on the consensus regarding what the likely extent of the impact of this bug will be, and how feasible it is to fix it in a very short time span.