Bug 431302

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