Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 81593 - xscreensaver isn't painting on entire screen on my docked laptop
Summary: xscreensaver isn't painting on entire screen on my docked laptop
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 9
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2003-01-10 22:19 UTC by George Karabin
Modified: 2007-04-18 16:49 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-09-01 01:18:18 UTC

Attachments (Terms of Use)
Log of XFree86 when docked (deleted)
2003-06-24 02:24 UTC, George Karabin
no flags Details

Description George Karabin 2003-01-10 22:19:15 UTC
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):


How reproducible:


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.
Actual results:

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.

Expected results:

The entire screen should be covered by the the screensaver, based on the actual
current resolution.

Additional info:

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?

Comment 1 George Karabin 2003-06-11 16:26:54 UTC
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
additional info....


>> -----Original Message-----
>> From:	George J Karabin []
>> 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:
>>> >Hi!
>>> >
>>> >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,
>>> >Lars

Comment 2 George Karabin 2003-06-13 20:29:29 UTC
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.

Comment 3 Jamie Zawinski 2003-06-19 10:21:39 UTC
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.

Comment 4 George Karabin 2003-06-24 02:24:13 UTC
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.

Comment 5 George Karabin 2003-06-24 02:26:33 UTC
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

Comment 6 George Karabin 2003-06-26 03:31:45 UTC
XF86VidModeGetViewPort is definitely reporting the wrong values. I filed a
report with XFree86 at .

Comment 7 Jamie Zawinski 2003-09-02 20:07:06 UTC
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."

Comment 8 Bill Nottingham 2003-09-02 20:39:08 UTC
Assigning to XFree86, closing as UPSTREAM, as this is a problem for upstream X
to handle at some point, hopefully.

Comment 9 Joshua Jensen 2004-07-19 15:33:10 UTC
A good point of reference for this bug is:

Comment 10 Mike A. Harris 2004-09-01 01:17:09 UTC
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.

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