gnome uses wrong screen size - does not fill the screen

[Vikas BN]

HI,

  I use a laptop Dell D610 with the AIT mobility M22 video card.
  I normally use the laptop when docked to the docking station
  which is connected to an external monitor (Dell 1905FP).

  I installed Gutsy a couple of days back and since then, it's not
  been able to switch to the resolution 1280x1024 (that the
  external monitor supports).

  I installed fglrx driver and that works well. I didn't have this issue
  with fiesty and ati open source drivers.

  I'll attach a screenshot of how the screen looks on the external
  monitor. Please revert if you need any more info.

-vikas

[david_ri (david-d-cox)]

I have EXACTLY the same issue on a Dell C640. I attached this snapshot in another bug report. This is also a security issue because the screensaver (shown) does not cover the whole screen, even when "locked," allowing access to files outside of the area that Ubuntu "thinks" is the full-screen area - i.e., the area delineated by the top and bottom panels in your photo, and by the screen saver in fullscreen preview mode in this photo. Some people are reporting that there is a blank window in movie players when playing videos. I also have that problem - the picture doesn't "appear" unless I drag the window OUTSIDE of the panels shown. If someone doesn't have an external monitor supporting a larger resolution, they would not even have that option. This is a serious problem and it occurred after upgrading from Feisty to Gutsy on my laptop. Interestingly, it does the same thing with both a clean install AND with running from the liveCD. I never had this screen geometry problem with Feisty.

[Tormod Volden (tormodvolden)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please attach your X server configuration file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.0.log) to the bug report as individual uncompressed file attachments using the "Attachment:" box below. Could you please also try to run without any /etc/X11/xorg.conf and let Xorg autodetect your display and video card? Please also attach the /var/log/Xorg.0.log from this attempt. Thanks in advance.

Please also attach the output from "xrandr".

Most probably the driver is seeing a second "ghost" screen that is using as primary, cloning the image to the secondary (and only real) screen. Try disabling the second output with "xrandr --output XXX --off"

[david_ri (david-d-cox)]

Here is my Xorg.conf file

[david_ri (david-d-cox)]

Here is my Xorg.0.log file

[david_ri (david-d-cox)]

Here is the output of xrandr. I know there's a way to "pipe the output" to a file, but I'm forgetting how to do that at the moment, so hopefully this is ok --

ddeangelis@ddeangelis69:~$ xrandr
Screen 0: minimum 320 x 200, current 1440 x 900, maximum 1920 x 1200
VGA-0 connected 1440x900+0+0 (normal left inverted right) 408mm x 255mm
   1440x900 59.9*+ 75.0 59.9
   1920x1200@60 60.0
   1680x1050@75 75.0
   1680x1050@60 60.0
   1600x1024@60 60.0
   1280x1024 75.0 59.9
   1440x900@75 75.0
   1440x900@60 60.0
   1280x854 54.6
   1280x800@75 75.0
   1280x800@60 60.0
   1280x768@75 75.0
   1280x768@60 60.0
   1280x720@60 60.0
   1280x720@50 50.0
   1152x768@54 54.8
   1024x768 75.1 70.1 60.0
   800x600@72 72.2
   800x600 72.2 75.0 60.3 56.2
   800x600@75 75.0
   800x600@60 60.3
   800x600@56 56.2
   640x480 75.0 72.8 60.0
   720x400 70.1
   640x360 69.4
LVDS connected 1024x768+0+0 (normal left inverted right) 0mm x 0mm
   1024x768 60.0*+ 60.0
   800x600 60.3 59.9
   640x480 59.9
S-video disconnected (normal left inverted right)
ddeangelis@ddeangelis69:~$

[david_ri (david-d-cox)]

Holy schmoly! The xandr thing worked! I did:

ddeangelis@ddeangelis69:~$ xrandr --output LVDS --off
ddeangelis@ddeangelis69:~$

and suddenly: Poof - the panel bar extended to the rest of the screen! If you were here, I'd buy you a drink!

Now, how do I make that permanent, and is it a bug?

(Note - in this effort, I haven't tried running without the xorg.conf file because the last time I did that, it ran through its gyrations and ended up producing a file that ONLY let me see the low-res screen - in other words, I was no longer able to crank the resolution beyond 1024 x 768. However, if you still need that, I'll save off my existing file and run it again. Please let me know. I'm so happy right now, I'd do anything!

[Tormod Volden (tormodvolden)]

Yes, it is a bug that the "ghost" screen is used for determining screen size. To disable this in xorg.conf, see "III.4. Disabling outputs" in http://wiki.debian.org/XStrikeForce/HowToRandR12

Running without an xorg.conf will not produce a new one. "sudo dpkg-reconfigure -phigh xserver-xorg" will make one. Or the "Screen and Graphics" GUI, but it can not yet be trusted with the new xrandr1.2 drivers, so just avoid it.

Thanks for the drink :)

[Vikas BN (vikas-bn)]

Hi Tormod,

  Thanks a lot for the tip! You get another drink :-)

On 10/25/07, Tormod Volden <> wrote:
>
> Yes, it is a bug that the "ghost" screen is used for determining screen
> size. To disable this in xorg.conf, see "III.4. Disabling outputs" in
> http://wiki.debian.org/XStrikeForce/HowToRandR12
>
> Running without an xorg.conf will not produce a new one. "sudo dpkg-
> reconfigure -phigh xserver-xorg" will make one. Or the "Screen and
> Graphics" GUI, but it can not yet be trusted with the new xrandr1.2
> drivers, so just avoid it.
>
> Thanks for the drink :)
>
> ** Changed in: xserver-xorg-video-ati (Ubuntu)
> Assignee: Tormod Volden (tormodvolden) => (unassigned)
> Status: Incomplete => Confirmed
>
> --
> [gutsy] ati open source driver issues with external monitor
> https://bugs.launchpad.net/bugs/156550
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Tormod Volden (tormodvolden)]

I read again your original description and wonder why I talk about a "ghost" screen :) You have a real screen on the laptop of course. I am just mixing up with other bug reports where there is only one real screen.

The problem is that with both screens enabled and in the default "clone" mode, the reported screen dimensions from the X server to the applications is the ones from the laptop screen and not the full virtual size reported by xrandr. Maybe the application (in this case gnome) uses the wrong method to probe for screen dimensions.

Can you please run xdpyinfo before and after the --off command and attach the output? e.g xdpyinfo > xdpyinfo-before.txt

I guess the ati driver is doing the right thing, but the X server or applications are not, so I reassign to xorg again. Ubuntu would also need a tool to correctly configure using xrandr1.2, and that's being worked on.

[Tormod Volden (tormodvolden)]

xdpyinfo actually reports "dimensions: 1280x1024 pixels" both before and after so I don't know how gnome gets it wrong.

[david_ri (david-d-cox)]

Although I've loaded Ubuntu and not Kubuntu, I also loaded KDE. If I choose KDE as the session environment upon login, it exhibits exactly the same problem.

Anyway, I'm attaching the before file here. The after will follow. These were done in GNOME.

[david_ri (david-d-cox)]

The after file.

[Bryce Harrington (bryce)]

Tormod, I think there are some dupes of this bug (I know it's been reported to me before), including in GNOME and Gnome Panel. Would you mind duping any xorg reports of this bug with those, so we have one bug report that includes all three packages?

[Kjell Krohn (kjell-krohn)]

Hi, I have perhaps a variation of this problem.

I have a Dell laptop with a broken monitor, so I use it as a desktop with an external monitor.
It has an ATI Radeon Mobility card in it. I see this problem since I upgraded to Gutsy, but also when I run both the Ubuntu as well as Kubuntu live-CDs. Feisty installation worked fine, as well as the Feisty live-CD works fine.

What I see in addition to already reported:
1. The log-in screen as well as the splash-screen after giving username and password shows this behavior
2. When I press the "K" button to bring up the menu, the menu pops up half-way up the screen, on the bottom of the top-left 1024x768 corner, I presume.
3. Maximizing a window only maximizes it to the top-lef 1024x768 part of the monitor.

However, running the xrandr command to shut off LVDS doesn't seem to do anything.
xpyinfo as well as xrandr shows identical information before and after, and nothing changes on the screen.

[Kjell Krohn (kjell-krohn)]

xpyinfo before

[Kjell Krohn (kjell-krohn)]

xpyinfo after

[Andrew (andrew-redhat-bugs)]

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

[Mamoru (mamoru-redhat-bugs)]

Jamie, any ideas?

[Jamie (jamie-redhat-bugs)]

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.

[Patrick (patrick-redhat-bugs)]

Have the same problem:
$ xscreensaver -verbose
xscreensaver 5.04, copyright (c) 1991-2006 by Jamie Zawinski <email address hidden>.
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.

[Patrick (patrick-redhat-bugs)]

Created attachment 263971
lspci -vvv on the affected box

[Patrick (patrick-redhat-bugs)]

Created attachment 263981
xorg.conf of the affected box

[Patrick (patrick-redhat-bugs)]

Created attachment 263991
Xorg.0.log

[Patrick (patrick-redhat-bugs)]

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?

[Mamoru (mamoru-redhat-bugs)]

cc-ing xgl maintainer.

[Patrick (patrick-redhat-bugs)]

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 xsc...

[Mamoru (mamoru-redhat-bugs)]

Thanks you for additional information.
Also changing assignee.

[Adam (adam-redhat-bugs)]

(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.

[Jamie (jamie-redhat-bugs)]

> 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.)

[Adam (adam-redhat-bugs)]

(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.

[Jamie (jamie-redhat-bugs)]

> 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.

[Adam (adam-redhat-bugs)]

(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.
> ...

[Tormod Volden (tormodvolden)]

Can you all please run: xdpyinfo -ext XINERAMA|grep head
just after starting X, before any xrandr commands? Preferably, run this in a Failsafe Terminal session (from the login window menu).

(Checking possible connection to http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=23b8ca8a373d919225de9739af7b064f650eceec)

[david_ri (david-d-cox)]

The results are:
ddeangelis@hqddeangelis69:~$ xdpyinfo -ext XINERAMA|grep head
  head #0: 1024x768 @ 0,0
  head #1: 1440x900 @ 0,0
ddeangelis@hqddeangelis69:~$

Same thing in a failsafe window (from the login) as within a regular terminal during regular boot, prior to xrandr.

After xrandr, the output is:

ddeangelis@hqddeangelis69:~$ xrandr --output LVDS --off
ddeangelis@hqddeangelis69:~$ xdpyinfo -ext XINERAMA|grep head
  head #0: 1440x900 @ 0,0
ddeangelis@hqddeangelis69:~$

[Vikas BN (vikas-bn)]

Hi,

  The output is as below:

  head #0: 1024x768 @ 0,0
  head #1: 1280x1024 @ 0,0

  I got this when I logged in to the 'Failsafe X Terminal' session in gdm.

-Vikas

[kell.hound (kell-hound)]

Hi!

with this information and some more google work i finally found a - I believe quite nice - way for me to automatize this fix!

due to a reference on http://mg.pov.lt/blog/t61.html I just tried his solution and voila gdm and gnome in 1280x800 right from scratch!

I just added in added in /etc/gdm/Init/Default in line 9 (right afte the variable declarations) my "xrandr --output TV --off"

GP

[David (david-redhat-bugs)]

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.

[david_ri (david-d-cox)]

Hi, GP -
Unfortunately for me, I added this line and it made no difference on my system. I found some interesting information on the redhat bug list (bug 389501) that talks about placement of screens in Xinerama, overlapping screens, etc. If I can stretch my brain around the sophisticated discussion, it seems to me that the window display server is overlapping the small laptop display (even though it's closed and should be off on my Dell C640) directly on top of the 1440x900 widescreen LCD I have connected to the VGA port. As long as the laptop display is on, the overlap persists, all applications think that the upper-left 1024x768 "piece" of my 1440x900 display is "maximized" - the panels only go part way across the screen, as does the screen saver, and maximizing windows only fill this portion of the screen. Interestingly, if I unmaximize windows, I can drag them to the right or manually increase their size and can use the rest of the 1440x900 screen just fine. This would make sense if the two screens were "overlapped" - I am dragging something across screens - except here, it's all on one monitor.

When I turn the LCD off by xrandr --output --LVDS --off, then the panels spring to full size on the 1440x900, maximize now fills the 1440x900 screen, and life is good. I suppose this is because the smaller rectangle that was somehow dictating what "maximize" means is now gone, so the fall-back becomes the larger display.

I hope this less than technically brilliant comment helps the smarter guys out a bit. :-)

[david_ri (david-d-cox)]

(oops - should be xrandr --output LVDS --off sorry 'bout the typo.)

[Matěj (matj-redhat-bugs)]

Launchpad # 147363 was considered duplicate of
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/131646 (just to have full
URL here).

[David (david-redhat-bugs)]

Is it a duplicate of
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/147363
?

[Matěj (matj-redhat-bugs)]

According to
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/147363/comments/5
147363 is a duplicate of 131646

[Adam (adam-redhat-bugs)]

(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.

[Jamie (jamie-redhat-bugs)]

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.

[Vikas BN (vikas-bn)]

Hi Tormod,

  I recently installed Hardy Alpha and it didn't have this issue.
  However, I just updated my installation after the update-manager
  prompted that there were new updates.

  So with the new updates, I have the same problem :-(
  It was working fine till I installed the updates now. After the restart
  it is exhibiting the same behaviour :-(

-Vikas

[Tormod Volden (tormodvolden)]

Vikas, was that Alpha 5? The new -ati 6.8.0 came just after it.

[Vikas BN (vikas-bn)]

Hi Tormod, I don't know :-). I installed Alpha 3 initially. After that I just update whenever there are updates.
Is there a way to find out which packages got installed after the last upgrade?

[Tormod Volden (tormodvolden)]

Vikas, /var/log/dpkg.log should give the necessary information. Try degrading to 6.7.197 again, https://edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/1:6.7.197-1ubuntu1 and pick your architecture under Builds, then "Resulting Binaries" on the left pane.

[Vikas BN (vikas-bn)]

Hi Tormod,

  Thanks for the info. Now I'm using the downgraded version of xserver-xorg and it works
  perfectly fine. I guess I'm going to stick with it till it's fixed in the latest version.

-Vikas

[Mamoru (mamoru-redhat-bugs)]

(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.

[Bryce Harrington (bryce)]

This sounds a LOT like the tv-out bugs with -intel, but is for LVDS. Presumably -ati needs some quirks for handling this situation.

[Bryce Harrington (bryce)]

Is anyone still seeing this with Hardy 8.04.1 and/or Intrepid?

[Vikas BN (vikas-bn)]

I've kept my Hardy updated, and I still see this issue. I don't know what you mean by 8.04.1. Is this some new release?

[Tormod Volden (tormodvolden)]

Vikas, 8.04.1 is just a new CD release with all updates to 8.04. If you have Hardy updated, you already have 8.04.1.

[Bryce Harrington (bryce)]

According to the debian bug tracker, this issue is now resolved in the version we have in Intrepid.

I'll leave a task open for Hardy in case anyone would like to investigate backporting the fix there.

[Steffen Torp (steffen-ubuntu)]

Sure this is fixed? I have the exact same look on my gnome-panel as the first post in this bug report, and I dist-upgraded to Intrepid today. gnome-panels are still limited to 1024x768 resolution, even though maximising an application would take up the full 1360x768 or 1680x1050.

[Bug (bug-redhat-bugs)]

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

[Bug (bug-redhat-bugs)]

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.

[Patrick (patrick-redhat-bugs)]

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

[Rolf Leggewie (r0lf)]

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".