Bug 389501

Summary: screensaver only uses part of the screen
Product: [Fedora] Fedora Reporter: Andrew Schultz <ajschult>
Component: xorg-x11-server-utilsAssignee: Adam Jackson <ajax>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 8CC: david-d, jwz, mtasaka, pcfe, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-09 02:27:22 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
lspci -vvv on the affected box
none
xorg.conf of the affected box
none
Xorg.0.log none

Description Andrew Schultz 2007-11-18 12:10:46 EST
When xscreensaver blanks the screen it only blanks part of it.  My screen is
1600x1200 and the part it uses is only 1358x737.

Version-Release number of selected component (if applicable):
5.04-1.fc8
This problem did not exist in the fedora7 version.

Steps to Reproduce:
1. xscreensaver &
2. xscreensaver-command -activate
Comment 1 Mamoru TASAKA 2007-11-19 06:28:15 EST
Jamie, any ideas?
Comment 2 Jamie Zawinski 2007-11-19 15:20:12 EST
Bug reports without verbose logs are usually useless.

But in this case, based on what was in another report, I think I can predict that the verbose log will say 
something like

xscreensaver: 13:27:37: Xinerama layout:
xscreensaver: 13:27:37:   + 0/0: 1600x1200+0+0
xscreensaver: 13:27:37:     1/0: 1360x768+0+0

which is to say, the new version of xinerama is reporting that there are two screens that OVERLAP.  Which 
is, in a word, bullshit.

Someone has suggested that perhaps this has something to do with
XRRGetOutputInfo()->connection
but that is, as far as I can tell,

1) a brand new interface, and 

2) completely, utterly undocumented.

So, as long as XRANDR continues to be an undocumented, experimental moving target, I have not the first 
clue what to do to work around this latest braindamage.
Comment 3 Patrick C. F. Ernzer 2007-11-19 18:11:44 EST
Have the same problem:
$ xscreensaver -verbose
xscreensaver 5.04, copyright (c) 1991-2006 by Jamie Zawinski <jwz@jwz.org>.
xscreensaver: running as pcfe/pcfe (500/500)
xscreensaver: in process 2427.
xscreensaver: 0: xscreensaver-gl-helper: GL visual is 0x23 (default).
xscreensaver: 1: xscreensaver-gl-helper: GL visual is 0x23 (default).
xscreensaver: running on display ":0.0" (2 Xinerama screens).
xscreensaver: vendor is The X.Org Foundation, 10300000.
xscreensaver: useful extensions:
xscreensaver:   MIT Screen-Saver  <-- not supported at compile time!
xscreensaver:   Shared Memory
xscreensaver:   Double-Buffering
xscreensaver:   Power Management
xscreensaver:   GLX
xscreensaver:   XF86 Video-Mode
xscreensaver:   Xinerama
xscreensaver:   Resize-and-Rotate
xscreensaver: screen 0 non-colormapped depths: 0 24.
xscreensaver: Xinerama layout:
xscreensaver:   + 0/0: 1600x1200+0+0
xscreensaver:     1/0: 1360x768+0+0
xscreensaver: selecting RANDR events
xscreensaver: 1: xinerama vp: 1360x768+0+0.
xscreensaver: 0: visual 0x23 (TrueColor,   depth: 24, cmap: default)
xscreensaver: 0: saver window is 0x1600001.
xscreensaver: 1: xinerama vp: 1360x768+0+0.
xscreensaver: 1: saver window is 0x1600005.
xscreensaver: selecting events on extant windows... done.
xscreensaver: awaiting idleness.
Comment 4 Patrick C. F. Ernzer 2007-11-19 18:12:18 EST
Created attachment 263971 [details]
lspci -vvv on the affected box
Comment 5 Patrick C. F. Ernzer 2007-11-19 18:14:14 EST
Created attachment 263981 [details]
xorg.conf of the affected box
Comment 6 Patrick C. F. Ernzer 2007-11-19 18:20:39 EST
Created attachment 263991 [details]
Xorg.0.log
Comment 7 Patrick C. F. Ernzer 2007-11-19 18:22:31 EST
this

(II) RADEON(0): Output VGA-0 using initial mode 1600x1200
(II) RADEON(0): Output DVI-0 using initial mode 1360x768
after xf86InitialConfiguration

in attachment of Comment #6 seems odd. The card is attached to the DVI to VGA
adapter that came with the card, I would kind of expect these values to be
identical, no?
Comment 8 Mamoru TASAKA 2007-11-20 01:25:06 EST
cc-ing xgl maintainer.
Comment 9 Patrick C. F. Ernzer 2007-11-20 06:18:35 EST
Changing component as this is a xrandr bug and not an xscreensaver bug.
xorg-x11-server-utils-7.3-1.fc8

If I disable the DVI-0 output (which does not really exist, c.f. Comment #7) as
follows

# xrandr -q
Screen 0: minimum 320 x 200, current 1600 x 1200, maximum 1920 x 1200
VGA-0 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1600x1200      75.0*+   70.0     65.0     60.0  
   1920x1200      75.0     72.8     70.0     60.0     60.0  
   1920x1080      74.9     69.9     60.0     59.9  
   1680x1050      84.9     74.9     69.9     60.0     59.9  
   1600x1024      60.2  
   1400x1050      85.3     85.0     74.8     70.0     70.0     60.0  
   1280x1024      85.0     75.0     60.0  
   1440x900       59.9  
   1280x960       85.0     60.0  
   1360x768       59.8     60.0  
   1280x800       85.0     75.0     70.0     60.0  
   1152x864       85.1     85.0     75.0     75.0     70.0     60.0  
   1280x768       85.0     75.0     70.0     60.0  
   1280x720       85.0     75.0     70.0     60.0  
   1152x768       54.8  
   1024x768       85.0     75.0     70.1     60.0  
   832x624        74.6  
   800x600        85.1     72.2     75.0     60.3     56.2  
   640x480        85.0     72.8     75.0  
   720x400        85.0  
   640x400        85.1  
   640x350        85.1  
None disconnected (normal left inverted right x axis y axis)
DVI-0 unknown connection 1360x768+0+0 (normal left inverted right x axis y axis)
0mm x 0mm
   1360x768       59.8*    60.0  
   1280x800       60.0  
   1152x864       60.0  
   1280x768       60.0  
   1280x720       60.0  
   1024x768       60.0  
   800x600        60.3  
   640x480        59.9  
# xrandr --output DVI-0 --off
# xrandr -q
Screen 0: minimum 320 x 200, current 1600 x 1200, maximum 1920 x 1200
VGA-0 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1600x1200      75.0*+   70.0     65.0     60.0  
   1920x1200      75.0     72.8     70.0     60.0     60.0  
   1920x1080      74.9     69.9     60.0     59.9  
   1680x1050      84.9     74.9     69.9     60.0     59.9  
   1600x1024      60.2  
   1400x1050      85.3     85.0     74.8     70.0     70.0     60.0  
   1280x1024      85.0     75.0     60.0  
   1440x900       59.9  
   1280x960       85.0     60.0  
   1360x768       59.8     60.0  
   1280x800       85.0     75.0     70.0     60.0  
   1152x864       85.1     85.0     75.0     75.0     70.0     60.0  
   1280x768       85.0     75.0     70.0     60.0  
   1280x720       85.0     75.0     70.0     60.0  
   1152x768       54.8  
   1024x768       85.0     75.0     70.1     60.0  
   832x624        74.6  
   800x600        85.1     72.2     75.0     60.3     56.2  
   640x480        85.0     72.8     75.0  
   720x400        85.0  
   640x400        85.1  
   640x350        85.1  
None disconnected (normal left inverted right x axis y axis)
DVI-0 unknown connection (normal left inverted right x axis y axis)
   1360x768       59.8     60.0  
   1280x800       60.0  
   1152x864       60.0  
   1280x768       60.0  
   1280x720       60.0  
   1024x768       60.0  
   800x600        60.3  
   640x480        59.9

And then restart xscreensaver, it works in fullscreen. Until I do this
xscreensaver behaves like described in the original report.

Additionally, mplayer will also run in a 1360x768 part of the screen until such
time that I delete DVI-0
Comment 10 Mamoru TASAKA 2007-11-20 06:22:28 EST
Thanks you for additional information.
Also changing assignee.
Comment 11 Adam Jackson 2007-11-20 09:45:54 EST
(In reply to comment #2)
> Bug reports without verbose logs are usually useless.
> 
> But in this case, based on what was in another report, I think I can predict
that the verbose log will say 
> something like
> 
> xscreensaver: 13:27:37: Xinerama layout:
> xscreensaver: 13:27:37:   + 0/0: 1600x1200+0+0
> xscreensaver: 13:27:37:     1/0: 1360x768+0+0
> 
> which is to say, the new version of xinerama is reporting that there are two
screens that OVERLAP.  Which 
> is, in a word, bullshit.

Overlapping Xinerama geometry has always been legal.  That's how people do crazy
things like overlap the edges of projectors to correct for vignetting.  Newer
versions of RANDR merely exacerbate the problem by making overlapping geometry
much more common, because it tries to clone all screens together if it can.

That is itself arguably the wrong behaviour, but it's what we've got right now.

The geometry reported by Xinerama will match that reported by RANDR, and you can
even get notified when the geometry changes by listening for ConfigureNotify on
the root window.  So you shouldn't have to do anything RANDR-specific here.  But
you do need to be prepared for the case where Xinerama regions overlap.  They
always could anyway.

> 2) completely, utterly undocumented.

Not completely, but also not conveniently.  There's no man pages for the newer
RANDR API, but the protocol definition and the API match up pretty precisely.

You can find the protocol here:

http://gitweb.freedesktop.org/?p=xorg/proto/randrproto.git;a=blob;h=6719cf800a93a346d82514fc035b4f05cd27792e;hb=3243afaa593f95bb89b1381dac2b920111ce36b1;f=randrproto.txt

But ignoring it and using Xinerama geometry instead is fine too, that's not
going away.
Comment 12 Jamie Zawinski 2007-11-20 14:55:42 EST
> Overlapping Xinerama geometry has always been legal.  That's how
> people do crazy  things like overlap the edges of projectors to correct
> for vignetting.  Newer versions of RANDR merely exacerbate the
> problem by making overlapping geometry much more common,
> because it tries to clone all screens together if it can.

Well something has changed recently, because now I'm getting mail from
people saying "hey, xscreensaver is suddenly not covering my screen".
These are not people doing crazy stuff with projectors, these are people
with out-of-the-box one-screen setups (or possibly, people with laptops)
who had this crap just suddenly start *happening* to them, because on
their vanilla setup, xinerama is suddenly reporting two screens that overlap.

> But ignoring it and using Xinerama geometry instead is fine too, that's
> not going away.

If "just ignore it and use xinerama geometry" were a solution, then there
would be no problem, because that's exactly what's going on right now.

So I have two questions:

1) What is the reason for the recent change?  Why are these people with
vanilla systems suddenly presenting two different xinerama rectangles,
and what is that supposed to mean?

2) When I am presented with two overlapping xinerama rectangles,
what am I expected to do, exactly?

The "just ignore it and use xinerama geometry" approach leads to me
creating two xscreensaver root-windows, which overlap, and running
savers on each of them.

(Currently there is a bug that they both end up using the size of the
second one, but even after I fix that, running two savers on the same
rectangle can't possibly be the right thing to do.)

Comment 14 Adam Jackson 2007-11-26 18:19:25 EST
(In reply to comment #12)
> > Overlapping Xinerama geometry has always been legal.  That's how
> > people do crazy  things like overlap the edges of projectors to correct
> > for vignetting.  Newer versions of RANDR merely exacerbate the
> > problem by making overlapping geometry much more common,
> > because it tries to clone all screens together if it can.
> 
> Well something has changed recently, because now I'm getting mail from
> people saying "hey, xscreensaver is suddenly not covering my screen".
> These are not people doing crazy stuff with projectors, these are people
> with out-of-the-box one-screen setups (or possibly, people with laptops)
> who had this crap just suddenly start *happening* to them, because on
> their vanilla setup, xinerama is suddenly reporting two screens that overlap.

Right.  RANDR propagates its output geometry into the Xinerama protocol, so that
clients that are only aware of Xinerama stand a chance of doing the right thing.
 RANDR also defaults to cloning the desktop by default (as much as it can), and
attempts to do this even for outputs where we can't really tell if they're
connected, like S-Video.

Therefore, the driver probably presents a "definitely connected" screen at, say,
1600x1200, and a "possibly connected" screen at some fallback size.  1360x768 is
certainly not a _good_ fallback size, but that's my bug, not yours.  (I have a
fix for it, just need to get it reviewed.)

> 2) When I am presented with two overlapping xinerama rectangles,
> what am I expected to do, exactly?
> 
> The "just ignore it and use xinerama geometry" approach leads to me
> creating two xscreensaver root-windows, which overlap, and running
> savers on each of them.

Sorry, I should have been clearer here.  While the Xinerama geometry might be
useful for telling you how monitors are physically placed, the logical rendering
model is still that every pixel is presented once, uniquely, and that any
geometry info you get out of RANDR or Xinerama is just telling you how many of
those pixels are physically being displayed and where they are in relation to
each other.

The root window is the canvas.  Extended geometry describes how much of the
canvas is occluded from view, and gives hints about where to place menus so
they're all on one screen and whatnot.  If you paint to the bounding box
covering all extended geometry, the output should look right.

You might as an optimization create just one window per output, if they're all
completely disjoint, as that will save some memory and probably perform better.
 But any overlap should be handled by painting to the screen as though it's a
solid canvas, meaning, find the bounding box of all the Xin rects and make a
window that size.

I wonder how OSX handles this.  I suspect they just don't allow any overlap
cases besides exact cloning.
Comment 15 Jamie Zawinski 2007-11-26 18:35:15 EST
> The root window is the canvas.  Extended geometry describes
> how much of the canvas is occluded from view, and gives
> hints about where to place menus so they're all on one
> screen and whatnot.  If you paint to the bounding box
> covering all extended geometry, the output should look
> right.

Well, xscreensaver doesn't work that way.  If it worked that
way, I wouldn't have to call Xinerama functions at all.  A
different screen saver is run on each *monitor*.  It does
not run a single saver that spans monitors and is then
clipped.  To accomplish this, xscreensaver needs to know
where the *glass* is.

You seem to be telling me, "you're no longer allowed to know
that."  I don't find that a particularly satisfying answer.

(The reason xscreensaver does it this way is simple: with 
screen savers, spanning monitor looks like ass with all but
a tiny handful of few savers.  That's why Apple does it this
was as well.)

> You might as an optimization create just one window per
> output, if they're all completely disjoint, as that will
> save some memory and probably perform better.  

What do you mean by "output"?

> I wonder how OSX handles this.  I suspect they just don't
> allow any overlap cases besides exact cloning.

Correct.  If you're not cloning, then the "Monitor
Arrangement" preference panel lets you drag the rectangles
representing every attached monitor around.  Edges are
constrained to at least partially touch (on top, bottom,
left or right), and rectangles cannot overlap.

However, screen savers are run "full screen" on each
*monitor*.  With screen savers, placement of monitors and
size of the virtual desktop canvas do not come into play at
all.
Comment 16 Adam Jackson 2007-11-27 13:03:23 EST
(In reply to comment #15)
> Well, xscreensaver doesn't work that way.  If it worked that
> way, I wouldn't have to call Xinerama functions at all.  A
> different screen saver is run on each *monitor*.  It does
> not run a single saver that spans monitors and is then
> clipped.  To accomplish this, xscreensaver needs to know
> where the *glass* is.
> 
> You seem to be telling me, "you're no longer allowed to know
> that."  I don't find that a particularly satisfying answer.

You can know it as well as the X server knows it.  The Xinerama geometry is
every piece of glass we're displaying to, which may include even glass that
we're not sure is physically present.  If you want to distinguish between
connected/disconnected/unknown, XRRGetOutputInfo() will tell you.

> (The reason xscreensaver does it this way is simple: with 
> screen savers, spanning monitor looks like ass with all but
> a tiny handful of few savers.  That's why Apple does it this
> was as well.)

Then you have your choice of what kind of ass to look like.

For the (sane) case where no outputs overlap you can run one xscreensaver window
each.  That's not changed.  For the case where they do overlap, you can do any of:

a) Run on the smallest of the overlapped outputs
b) Run on each of the outputs
c) Run on the whole canvas

a) is what you're doing, it seems, and this doesn't blank the whole screen.  b)
and c) will both look weird, but c) will probably look less wrong; b) will have
weird seams at xscreensaver window edges, whereas c) will just have some of the
screensaver potentially not visible.

This isn't an answer I'm happy with either.  I don't like the display model in
X, but it's a bit difficult to change at this point.  Technically,
implementation-wise, it's easy, but users are noisy creatures and think it's a
feature.

> > You might as an optimization create just one window per
> > output, if they're all completely disjoint, as that will
> > save some memory and probably perform better.  
> 
> What do you mean by "output"?

Agh terminology disaster.  The RANDR model is: an X protocol screen maps to one
GPU (or more, but that's not finished yet).  One GPU may have one or more CRTCs.
 A CRTC is really just a region of pixels that's being scanned out.  Each CRTC
may have one or more outputs connected to it.  An output is a physical
presentation device.  The Xinerama geometry is a mirror of the CRTC geometry. 
So in the above, I should have said "one window per CRTC".

(In the above where I say "the Xinerama geometry is every piece of glass we're
displaying to", I'm still not lying: a CRTC doesn't exist in the geometry if you
haven't enabled it, and you can't do that unless there's at least one output
attached to it.)

Now that I think about it I don't mean "all disjoint".  I mean "all disjoint
after eliminating identical rectangles", since you could (theoretically) have a
geometry like:

1: 800x600+0+0
2: 800x600+0+0
3: 800x600+800+0

Here 1 and 2 are cloned but 3 is immediately right of both of them, so 1 and 2
should be treated as a single xscreensaver view.

> > I wonder how OSX handles this.  I suspect they just don't
> > allow any overlap cases besides exact cloning.
> 
> Correct.  If you're not cloning, then the "Monitor
> Arrangement" preference panel lets you drag the rectangles
> representing every attached monitor around.  Edges are
> constrained to at least partially touch (on top, bottom,
> left or right), and rectangles cannot overlap.
> 
> However, screen savers are run "full screen" on each
> *monitor*.  With screen savers, placement of monitors and
> size of the virtual desktop canvas do not come into play at
> all.

My kingdom for a real window system.
Comment 18 David DeAngelis 2008-02-15 00:24:54 EST
Gentlemen - Please excuse these comments if they are out of scope here. I run
Ubuntu and have had this problem as a user since 7.10 was released. The problem
on my Dell C640 with regards to the screensaver is identical to what has been
described here, however the problem is NOT just the screensaver. When I boot
with my laptop closed and a 1440x900 LCD connected to the VGA port, the whole
screen lights up and is usable, however the menu bars only extend to the
1024x768 region (upper left corner) of the screen. ALL applications think this
is the Maximized size, although non-maximized screens can easily be dragged past
(to the right of) this region on the large screen, and they show up fine. When I
do xrandr --output LVDS --off, the LCD on the laptop shuts of, the menu bar on
the 1440x900 springs to cover the full width of the larger display, and life is
good. This exactly sounds like the overlapping rectangles issue.

However, my point is that the problem goes beyond screensavers. More can be read
about this on the ubuntu site, bug number 147363. I hope this helps. 
Comment 19 Matěj Cepl 2008-02-15 06:20:20 EST
Launchpad # 147363 was considered duplicate of
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/131646 (just to have full
URL here).
Comment 20 David DeAngelis 2008-02-15 18:50:40 EST
Is it a duplicate of
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/147363
?
Comment 21 Matěj Cepl 2008-02-16 10:06:35 EST
According to
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/147363/comments/5
147363 is a duplicate of 131646
Comment 22 Adam Jackson 2008-02-26 15:46:07 EST
(In reply to comment #18)

> However, my point is that the problem goes beyond screensavers. More can be read
> about this on the ubuntu site, bug number 147363. I hope this helps. 

Yes, it does.

The output setup heuristics have been fixed so that we only attempt to light up
"unknown" outputs (ones that we only think are connected) if there are no
definitely-connected outputs.  I have another fix pending that will try much
much harder to set up exactly the same mode on all outputs during initial
configuration.

This is about as far as you can punt the problem while still attempting to use
"clone" as a default policy.  For Xorg 7.5 (probably F10) I hope to have enough
of the remaining bugs fixed that we can reasonably do right-of placement as the
default policy like a sensible display system.
Comment 23 Jamie Zawinski 2008-02-26 16:29:51 EST
I've added some code to xscreensaver that attempts to ignore the goofier geometries, e.g., when two 
rectangles overlap, it chooses the larger one; and when two rectangles intersect, it chooses the earlier 
one.

Can you give me some examples of the sorts of ridiculous geometries that are likely to be encountered in 
the real world, so that I can test this?  I don't have access to any machines that exhibit this behavior, and 
don't particularly understand what the implications of laptop/desktop/external monitors are with this new 
RANDR stuff.
Comment 24 Mamoru TASAKA 2008-03-04 02:34:21 EST
(In reply to comment #23)
> I've added some code to xscreensaver that attempts to ignore the goofier
geometries, e.g., when two 
> rectangles overlap, it chooses the larger one; and when two rectangles
intersect, it chooses the earlier 
> one.

Now Fedora's xscreensaver is upgraded to 5.05.
Comment 25 Bug Zapper 2008-11-26 03:33:28 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 26 Bug Zapper 2009-01-09 02:27:22 EST
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 27 Patrick C. F. Ernzer 2009-10-22 11:01:48 EDT
both the GPU and the motherboard I was experiencing this on have been given to (two separate) friends. As such I will not be able to try and reproduce on F11 or F12