Bug 431302 - compiz doesn't know what is the full screen resolution
compiz doesn't know what is the full screen resolution
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-i810 (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
:
: 374371 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-02 06:35 EST by Valent Turkovic
Modified: 2008-04-11 09:33 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-04 15:45:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg.0.log (199.27 KB, text/plain)
2008-02-02 06:37 EST, Valent Turkovic
no flags Details
maximized window (274.59 KB, image/png)
2008-02-02 06:39 EST, Valent Turkovic
no flags Details
after clicking in task bar (173.45 KB, image/png)
2008-02-02 06:40 EST, Valent Turkovic
no flags Details
kde4 bug (1.20 MB, image/png)
2008-02-04 16:34 EST, Valent Turkovic
no flags Details
Xinerama test tool (622 bytes, text/x-csrc)
2008-02-05 02:02 EST, Valent Turkovic
no flags Details
false maximized window (200.37 KB, image/png)
2008-02-12 03:14 EST, Valent Turkovic
no flags Details
it maximizes (177.03 KB, image/png)
2008-02-12 03:17 EST, Valent Turkovic
no flags Details
mozilla prism (140.18 KB, image/png)
2008-02-12 03:21 EST, Valent Turkovic
no flags Details

  None (edit)
Description Valent Turkovic 2008-02-02 06:35:46 EST
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:
Comment 1 Valent Turkovic 2008-02-02 06:37:10 EST
Created attachment 293785 [details]
Xorg.0.log
Comment 2 Valent Turkovic 2008-02-02 06:39:00 EST
Created attachment 293786 [details]
maximized window

I get this "false" maximized window when I maximize
Comment 3 Valent Turkovic 2008-02-02 06:40:59 EST
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.
Comment 4 Matěj Cepl 2008-02-04 09:25:29 EST
Blaming compiz.
Comment 5 Valent Turkovic 2008-02-04 16:34:30 EST
Created attachment 293945 [details]
kde4 bug

kde4 exhibiting same bug
Comment 6 Valent Turkovic 2008-02-04 16:35:50 EST
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?
Comment 7 Valent Turkovic 2008-02-05 02:02:11 EST
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
Comment 8 Valent Turkovic 2008-02-05 02:02:40 EST
Created attachment 293981 [details]
Xinerama test tool
Comment 9 Valent Turkovic 2008-02-05 02:03:05 EST
$ 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]$ 

Comment 10 Valent Turkovic 2008-02-05 02:03:32 EST
./test 
Head 0: num 0, Origin 0 0, Size 1280 1024
Head 1: num 1, Origin 0 0, Size 1280 800
Comment 11 Danny Baumann 2008-02-05 03:31:27 EST
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.
Comment 12 Matěj Cepl 2008-02-05 08:43:00 EST
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).
Comment 13 Valent Turkovic 2008-02-06 10:38:34 EST
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
Comment 14 Adam Jackson 2008-02-11 15:43:39 EST
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.
Comment 15 Søren Sandmann Pedersen 2008-02-11 17:29:42 EST
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.
Comment 16 Valent Turkovic 2008-02-12 03:14:35 EST
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.
Comment 17 Valent Turkovic 2008-02-12 03:17:25 EST
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.
Comment 18 Valent Turkovic 2008-02-12 03:21:41 EST
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?
Comment 19 Valent Turkovic 2008-02-18 07:34:10 EST
Is there some other way I can contribute in fixing this bug?
Comment 20 Adam Jackson 2008-02-18 11:06:23 EST
(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.
Comment 21 Danny Baumann 2008-02-29 04:55:46 EST
After some discussion on IRC, I agree to comment #20 and withdraw my comment
quoted in comment #7.

Consider this work-in-progress upstream.
Comment 22 Matěj Cepl 2008-02-29 07:53:07 EST
OK, so this bug goes to ajax for admitting his guilt ;-), but reporter could you
also file a new maximizing bug for compiz, please?
Comment 23 Valent Turkovic 2008-03-03 07:45:51 EST
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.
Comment 24 Valent Turkovic 2008-03-03 07:52:15 EST
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
Comment 25 Adam Jackson 2008-03-04 15:45:25 EST
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.
Comment 26 Danny Baumann 2008-03-11 07:08:46 EDT
This problem should now be fixed upstream as well; Compiz now tries to behave as
smart as it can about overlapping outputs.
Comment 27 Matěj Cepl 2008-04-11 09:33:41 EDT
*** Bug 374371 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.