Description of problem:
I have a laptop that runs at 1280x1024 when using its built-in LCD display, and
at 1600x1200 when attached to my docking station's monitor. When xscreensaver
runs when connected to the docking station, it will only cover up the
lower-right portion of the screen. The upper and left edge show the desktop
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Attach a laptop to a docking station with a higher resolution on the dock's
monitor than on the laptop's LCD.
2. Use the Start-here: Screensaver preferences to preview a screensaver.
When xscreensaver runs when connected to the docking station, it will only cover
up the lower-right portion of the screen. The upper and left edge show the
desktop background. The resolution of the screensaver is correct when using the
laptop's built-in display.
The entire screen should be covered by the the screensaver, based on the actual
I've played around with the monitor setting in 'neat', setting it to use both
the LCD display and the external monitor. Neat is currently configued with my
external monitor settings (which seem to work fine when the LCD's running). I'm
wondering if something happened when the OS was installed (running on the LCD)
that pre-set a resolution that xscreensaver is always looking at?
I'm adding this note for someone who was having some difficulty getting a
comment added to bugzilla....
Subject: RE: xscreensaver LCD and external monitor RH9
not able to update with additional info on the web though,
got this error message:
You tried to change the component field from AfterStep-APPS to xscreensaver,
but only the owner or submitter of the bug, or a sufficiently empowered
user, may change that field.
seems strange.. Im not trying to change anything, just adding some text to
>> -----Original Message-----
>> From: George J Karabin [SMTP:email@example.com]
>> Sent: Tuesday, June 10, 2003 6:20 PM
>> To: Jonsson Lars T
>> Subject: Re: xscreensaver LCD and external monitor RH9
>> No, I haven't found it. It would help if you posted your comments on the
>> bug report - if someone else can verify the bug, maybe the maintainer
>> will take it more seriously.
>> Jonsson Lars T wrote:
>>> >I have the same problem as you have with the screensaver not covering the
>>> >whole screen when using it in the dockstation..
>>> >I wonder if you have fix it?
>>> >Best regards,
Here's another one:
Ed Saipetch wrote:
>I'm having the same problem as you. Here's another set of comments to
>add to the bug report to help give it some weight. All the circumstances
>are the same as what you experienced.
I'm pretty sure this is an X server bug.
What it means is that, while the size of your root window is 1600x1200, and all
of it is visible, the X server (via the funtions XF86VidModeGetViewPort and
XF86VidModeGetModeLine) is reporting that only a 1280x1024 subsection of that
window is actually visible on the screen.
If you run with -verbose, you'll see something like this on stderr:
xscreensaver: vp is 1280x1024+479+359
which is not the case. But xscreensaver has no way to know that your X server
can't be trusted.
Created attachment 92575 [details]
Log of XFree86 when docked
This log shows XFree86 startup when my laptop's docked. 1400x1050 is listed as
the "Panel Size", but 1600x1200 as "Virtual size", "Default Mode" and any
number of other things.
I'm not sure if the log file I attached will show you anything you don't already
know. Either there's no way for you to get what you want from X, as you've
already stated, or maybe the log file will hint at some reliable bit of
information that xscreensaver could look for. In any case, thanks for looking at
XF86VidModeGetViewPort is definitely reporting the wrong values. I filed a
report with XFree86 at
For the record, the xfree86 URL has changed to
They have also closed the bug. As far as I can tell, the reason for this was,
"this is an X server bug, but it's pretty hard to fix. Therefore, closing."
Assigning to XFree86, closing as UPSTREAM, as this is a problem for upstream X
to handle at some point, hopefully.
A good point of reference for this bug is:
Upstream XFree86 doesn't appear to be willing to fix this issue.
You may want to file a similar bug report in the upstream X.Org
bugzilla if this problem is still present in X.Org sources as well,
since X.Org is the current upstream X11 project we're using nowadays.
If the problem persists in X.Org in fedora devel, feel free to
update this report with your upstream X.Org bug report URL and
we'll watch the status at the new location.
Setting status to "WONTFIX", as we no longer use XFree86 in our
current development codebase.