Description of problem: When I enable "Desktop effects" (compiz) I see strange behavior on my external monitor that I have connected to my laptop. When I press maximise it doesn't maximise to full screen but only to 4/5 of the full screen (see the accachement). When I click in the task bar on some other window and then back to one that is maximized then it maximizes as it should. But on first click in that maximized window it again snaps back to 4/5 size of full screen. Really strange. Also in KDE 4.0 I se that KDE task bar is also not on the bottom of the screen. And I see this behavior in Rawhide also as in Fedora 8. I have laptop with intel chip and internal monitor is on 1280x800 and external is 1280x1024 resolution. Version-Release number of selected component (if applicable): How reproducible: all the time Steps to Reproduce: 1. start desktop effects 2. open any window 3. click maximize 4. click in task bar to different window 5. click in taskbar in maximized window 6. click inside maximized window Actual results: Expected results: Additional info:
Created attachment 293785 [details] Xorg.0.log
Created attachment 293786 [details] maximized window I get this "false" maximized window when I maximize
Created attachment 293787 [details] after clicking in task bar after clicking in task bar I get really maximized window, until I click inside, than it snaps back to "false" maximized windows as seen on previous screenshot.
Blaming compiz.
Created attachment 293945 [details] kde4 bug kde4 exhibiting same bug
Matej are you sure it is compiz? Look at KDE4 screenshot. Same bug and AFAIK KDE4 doesn't use compiz but uses its own compositing engine. Could this be some underlying bug? X.org maybe?
compiz devel Danny Baumann said this: This looks like broken Xinerama information to me. I will attach a test tool - please provide the output of that as well as the output of xdpyinfo. and also gave me a test tool to compile and run. in order to compile it you need to install dependencies first: yum install libXinerama-devel
Created attachment 293981 [details] Xinerama test tool
$ xdpyinfo name of display: :0.0 version number: 11.0 vendor string: The X.Org Foundation vendor release number: 10300000 X.Org version: 1.3.0 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: window 0x5a00021, revert to Parent number of extensions: 33 BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DPMS Extended-Visual-Information GLX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD RANDR RECORD RENDER SECURITY SGI-GLX SHAPE SYNC TOG-CUP X-Resource XAccessControlExtension XC-APPGROUP XC-MISC XFIXES XFree86-Bigfont XFree86-DGA XFree86-DRI XFree86-Misc XFree86-VidModeExtension XINERAMA XInputExtension XKEYBOARD XTEST XVideo default screen number: 0 number of screens: 1 screen #0: dimensions: 1280x1024 pixels (376x301 millimeters) resolution: 86x86 dots per inch depths (7): 24, 1, 4, 8, 15, 16, 32 root window id: 0x7b depth of root window: 24 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x20 default number of colormap cells: 256 preallocated pixels: black 0, white 16777215 options: backing-store NO, save-unders NO largest cursor: 64x64 current input event mask: 0x7a803f KeyPressMask KeyReleaseMask ButtonPressMask ButtonReleaseMask EnterWindowMask LeaveWindowMask ExposureMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask number of visuals: 17 default visual id: 0x23 visual: visual id: 0x23 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x24 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x25 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x26 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x27 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x28 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x29 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x2a class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x2b class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x2c class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x2d class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x2e class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x2f class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x30 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x31 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x32 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x79 class: TrueColor depth: 32 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits [valentt@valent Desktop]$
./test Head 0: num 0, Origin 0 0, Size 1280 1024 Head 1: num 1, Origin 0 0, Size 1280 800
Perhaps it's better to reference our bug report ;-) http://bugs.opencompositing.org/show_bug.cgi?id=765 As said there, I'm pretty sure it's a driver problem so this bug IMO should be assigned to the intel driver.
OK, giving up -- moving back to intel driver. (BTW, I always thought that compiz-kde is what's used on KDE as a compositing window manager, but I have no clue about KDE lately).
latest rawhide uses intel 2.2 driver and I see the same issue there. Fedora 8 uses intel drive 2.1. Is there any newer driver and how can I test it? On koji I see only 2.2 intel driver (xorg-x11-drv-i810) http://koji.fedoraproject.org/koji/buildinfo?buildID=30883
You have overlapping display rectangles. You hit maximize. What should it maximize to? If you max to the smaller rectangle you get the behaviour you see here. If you max to the larger one then one of your monitors has bits off the screen. At any rate, the driver is merely telling the truth. Not an X bug, blaming metacity.
If there is one thing this is not, it's a metacity bug. Metacity is the one window manager nobody has reported this against. If I had to guess, the problem here is that the Intel driver is not actually telling the truth. It is claiming that the user has overlapping display rectangles when that is not actually the case. Back to i810. Feel free to blame compiz if you think the driver is telling the truth.
Created attachment 294636 [details] false maximized window Firefox in foreground is "maximized" but as you can see it is not really. Other windows in background are manually resized.
Created attachment 294637 [details] it maximizes When I click in the taskbar on "false maximized" windows then it really maximizes as you can see in the attachment. But when I click inside the windows it changes back to "false maximized" size as shown in previous attachment.
Created attachment 294638 [details] mozilla prism Mozilla Prism is a single window browser that I tested on Fedora, and it is beta software but shows one different behavior - even when it is maximizes by clicking on it in the taskbar windows is maximized but application sees only the "false maxmimized" size. This looks like metacity bug, right?
Is there some other way I can contribute in fixing this bug?
(In reply to comment #15) > If I had to guess, the problem here is that the Intel driver is not actually > telling the truth. It is claiming that the user has overlapping display > rectangles when that is not actually the case. Sure it's the truth. Look at the X log. He's got a VGA device attached that's 1280x1024, and an LVDS that's 1280x800. > Back to i810. Feel free to blame compiz if you think the driver is telling the > truth. That the driver defaults to "all outputs have the same origin" instead of "all outputs have the same size and origin" is possibly a bug. That we don't do RightOf placement instead of the current crappy placement heuristic is certainly unpleasant. Either of these, we can fix. But maximization is the wm's bug, period.
After some discussion on IRC, I agree to comment #20 and withdraw my comment quoted in comment #7. Consider this work-in-progress upstream.
OK, so this bug goes to ajax for admitting his guilt ;-), but reporter could you also file a new maximizing bug for compiz, please?
http://bugs.opencompositing.org/show_bug.cgi?id=765 I have done that already but got bounced a few times... I'll update the compiz bug with your conclusion. Cheers.
the compiz people said that this is driver problem: http://bugs.opencompositing.org/show_bug.cgi?id=765#c6 but I reopened the bug on compiz bugzilla
This is fixed about as hard as the server can fix it in xorg-x11-server-1.4.99.900-0.28.20080304.fc9, headed to koji as we speak. We'll now try really really hard to do avoid creating overlapping non-identical outputs during initial configuration.
This problem should now be fixed upstream as well; Compiz now tries to behave as smart as it can about overlapping outputs.
*** Bug 374371 has been marked as a duplicate of this bug. ***