Bug 529045 - firstboot does not play well with multihead situations now X defaults to spanning
firstboot does not play well with multihead situations now X defaults to span...
Status: CLOSED DUPLICATE of bug 526836
Product: Fedora
Classification: Fedora
Component: firstboot (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Chris Lumens
Fedora Extras Quality Assurance
Depends On:
Blocks: F12Beta/F12BetaBlocker
  Show dependency treegraph
Reported: 2009-10-14 14:32 EDT by Adam Williamson
Modified: 2009-10-14 15:55 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-10-14 14:43:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Adam Williamson 2009-10-14 14:32:39 EDT
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:


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:


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.
Comment 1 Adam Williamson 2009-10-14 14:43:45 EDT

*** This bug has been marked as a duplicate of bug 526836 ***

Note You need to log in before you can comment on or make changes to this bug.