Bug 419 - XF86VidModeGetModeLine reports wrong mode when laptop is in docking station
Summary: XF86VidModeGetModeLine reports wrong mode when laptop is in docking station
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Xorg Project Team
QA Contact:
URL: http://plausible.org/andy/xvp.c
Depends on:
Reported: 2004-04-07 15:14 UTC by Andy Ross
Modified: 2007-02-22 14:26 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Description Andy Ross 2004-04-07 15:14:59 UTC
I reported this a while back to the XFree86 bugzilla.  It was closed
there without resolution, and is still present in the current xorg
server in the FC2 rawhide distribution, so I thought I'd ping you guys
again.  Comments in the original bugs
http://bugs.xfree86.org/show_bug.cgi?id=421) indicate that this is a
design issue that needs to be addressed.


The XServer properly (and surprisingly) understands the difference between the
1024x768 LCD display on my IBM T30 laptop and the monitor to which it is
attached via the port replicator.  Starting up the server while docked results
in a nice 1400x1050 desktop, while initialization without the monitor attached
ejects all the unsupported modes and drops down to 1024x768.

However, xscreensaver on the large monitor still displays itself into only a
1024x768 window; very strange indeed.

I tracked this down to the fact that xscreensaver uses XF86VidModeGetModeLine
and XF86VidModeGetViewPort to get the display size (so that it displays only one
"screen worth" of information in virtual desktop mode) instead of the more
pedestran DisplayWidth/DisplayHeight macros (which return the correct results) 
The current mode line reported while docked is, in fact, a 1024x768 mode.  This
has to be wrong.

The link points to a trivial C program I wrote to demonstrate the issue.  It
produces the following results, even while the screen is demonstrably set to a
higher resolution mode:

m.hdisplay = 1024
m.hsyncstart = 1040
m.hsyncend = 1176
m.htotal = 1344
m.hskew = 0
m.vdisplay = 768
m.vsyncstart = 770
m.vsyncend = 776
m.vtotal = 806
m.flags = 0x80000000
m.privsize = 0
dotClock = 65000
vpx = 74
vpy = 0
DisplayWidth(d, 0) = 1400
DisplayHeight(d, 0) = 1050
Comment 1 Chris Lee 2005-07-03 19:20:35 UTC
Does this still happen with the latest released X.org? 
Comment 2 Andy Ross 2005-07-04 08:46:06 UTC
I don't have that machine anymore, so unfortunately I can't check.  The comments
in the xfree86 bug 421 indicate that this is a design issue, though, so I'd be
doubtful that it would be silently fixed by other changes.
Comment 3 Timo Jyrinki 2007-02-22 14:26:12 UTC
Marking broken (status null/blank) bugs in xorg with no activity in a long time as fixed. Please reopen if you think it's necessary, but first do a search if a similar bug report is already filed and in a NEW/ASSIGNED state. These bugs do not currently show in most search results as they do not have any status.

Sorry for this janitorial spam, you know where to send hate mails to when your inbox gets full of bugs you're subscribed to.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.