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
Jamie, any ideas?
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.
Have the same problem: $ xscreensaver -verbose xscreensaver 5.04, copyright (c) 1991-2006 by Jamie Zawinski <jwz>. 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.
Created attachment 263971 [details] lspci -vvv on the affected box
Created attachment 263981 [details] xorg.conf of the affected box
Created attachment 263991 [details] Xorg.0.log
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?
cc-ing xgl maintainer.
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
Thanks you for additional information. Also changing assignee.
(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.
> 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.)
(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.
> 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.
(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.
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.
Launchpad # 147363 was considered duplicate of https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/131646 (just to have full URL here).
Is it a duplicate of https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/147363 ?
According to https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/147363/comments/5 147363 is a duplicate of 131646
(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.
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.
(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.
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
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.
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