! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
TwinView Xinerama extensions with different monitor heights results in mispla...
Status:
RESOLVED: FIXED
Severity:
trivial
Product:
Xfce4-panel

Comments

Description Steven Robertson 2006-01-09 21:09:00 CET
I am using TwinView, a feature of the nVidia driver, to render a single
framebuffer on two separate displays.  The nVidia drivers use Xinerama
extensions to apprise the window manager of each virtual screen's dimensions. 
My current configuration spans one 1680x1050 monitor and one 1280x1024 monitor.
 Because these are different heights, there is actually 26 pixels of framebuffer
"beneath" the fixed viewing pane of the second monitor.  XFCE does a good job of
managing windows in this configuration: opening new ones on the monitor with the
cursor, avoiding spanning windows, placing the panel properly, etc.  

However, if I maximise a window on the second monitor, the window is sized that,
with a properly-aligned top, the bottom 26 pixels or so are beneath the panel. 
Should I disable the panel, the window maximises to the full height of the
framebuffer -- which means the lower 26 pixels are drawn off-screen.  It's as if
the maximize routine places the top, then determines the bottom by examining the
height of the framebuffer, subtracting from that the height of the panel, and
places the bottom there.

To fix this issue, the routine should instead examine the bottom of the window
as determined by Xinerama.  I will browse the source and attempt a patch, but
I'm not an expert coder, so it may be more rapidly done by someone more familiar
with XFCE.

Thanks for your time!
Comment 1 Olivier Fourdan editbugs 2006-01-09 21:16:23 CET
I'm not sure the bug is in xfwm4, because Xinerama is being supported for years
and pretty well tested.

Can you try without twinview and just Xinerama? TwinView has caused some issues
in the past.
Comment 2 Olivier Fourdan editbugs 2006-01-09 21:20:14 CET
Created attachment 389 
Display current display and screen(s) size

Can you compile and run the attached test program and post the result?
Comment 3 Steven Robertson 2006-01-10 02:40:12 CET
Current display has 1 screen(s) :
  - Screen 0, position (1680, 0), size (1280, 1024)

nVidia's drivers, due to an "errata" ("not a bug!" say them), always put the
screen on VGA (as opposed to DVI-D) as the first monitor.  Since my larger
screen is leftOf my smaller screen, the numbers make sense.

Hope this helps; I'm happy to do anything else you can think of.
Comment 4 Olivier Fourdan editbugs 2006-01-10 11:33:11 CET
> Current display has 1 screen(s) :
>   - Screen 0, position (1680, 0), size (1280, 1024)

=> That means that there is only one screen seen by gtk+, and therefore by xfwm4
that relies on gtk+, so there is no 2-screen Xinerama layout reported. That
explains why both screens have the same height, there in no 2 screens, but just one.

That's not a bug in xfwm4, sorry. Disable NVidia TwinView and you should be fine.
Comment 5 Olivier Fourdan editbugs 2006-01-10 11:45:58 CET
Created attachment 390 
Display current display, screen(s) and monitor(s) size(s)

Wooops! Sorry, my previous test program shows nothing at all. So please also
disregard my previous comment!

Can you try this new version, it now includes the monitors sizes and should
tell if the Xinerama configuration is correctly reported.

Thanks, and sorry again,
Regards,
Olivier.
Comment 6 Steven Robertson 2006-01-10 20:26:30 CET
Current display has 1 screen(s) :
  - The screen #0 has 2 monitor(s) attached:
    * Screen #0, monitor #0, position (1680, 0), size (1280, 1024)
    * Screen #0, monitor #1, position (0, 0), size (1680, 1050)

That makes more sense.  And no worries -- you're helping *me* by doing this.
Comment 7 Olivier Fourdan editbugs 2006-01-10 20:51:50 CET
That looks just fine. So maybe I misunderstand the problem. Can you take a
screenshot (includign both monitors) showing what doesn't work as expected?

TIA
Olivier.
Comment 8 Olivier Fourdan editbugs 2006-01-10 20:55:29 CET
Oh, and I forgot, what xfce/xfwm4 version is it (try xfwm4 --version)?
Comment 9 Steven Robertson 2006-01-11 09:56:19 CET
Created attachment 391 
Screenshot (with captions) displaying problem.

This should make the problem a little more clear.

Note: I discovered something incorrect about my earlier explanation. 
Apparently. when I slide the panel over to the second monitor, maximizing works
properly on *both* monitors (no part of any window in the not-visible space). 
Could the problem be in how the panel determines its "bounding box" or
whatever?  Just guessing.
Comment 10 Olivier Fourdan editbugs 2006-01-11 20:03:03 CET
Ok, sounds like a bug in the panel which doesn't set its partial struts
correctly in Xinerama.

According to the standard:

http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2507618

<i>For example, for a panel-style Client appearing at the bottom of the screen,
50 pixels tall, and occupying the space from 200-600 pixels from the left of the
screen edge would set a bottom strut of 50, and set bottom_start_x to 200 and
bottom_end_x to 600. Another example is a panel on a screen using the Xinerama
extension. Assume that the set up uses two monitors, one running at 1280x1024
and the other to the right running at 1024x768, with the top edge of the two
physical displays aligned. If the panel wants to fill the entire bottom edge of
the smaller display with a panel 50 pixels tall, it should set a bottom strut of
306, with bottom_start_x of 1280, and bottom_end_x of 2303. <b>Note that the
strut is relative to the screen edge, and not the edge of the xinerama
monitor.</b></i>

From what I see in your screenshot, the window is not correctly maximized
because the panel set its partial struts relative to the (smaller) xinerama
monitor on which it's running and not the actual screen size, ie the struts
should be (26 + panel height) because the screen is 26 pixels smaller than the
actual screen size.

This could be confirmed by using xprop and clicking onto the panel with the
cross. Steven can you try the following command on the panel and post the result
in that bug report please?

xprop | grep NET_WM_STRUT_PARTIAL

If the fourth argument of the partial struts is equal to the panel height, then
the 26 pixel difference is not taken into account as it should.

Jasper, I copy you on this bug because I believe it's rather a panel bug.
Comment 11 Steven Robertson 2006-01-11 22:43:23 CET
_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 42, 0, 0, 0, 0, 0, 0, 1818, 2821

My panel is Medium size.  I don't have a screen ruler, but I can tell you the
window asks to be 42 pixels wide:

WM_NORMAL_HINTS(WM_SIZE_HINTS):
                program specified minimum size: 1003 by 42
                program specified maximum size: 1003 by 42


Seems that's it!  Thanks for the quick responses -- let me know if I can do
anything else.
Comment 12 Olivier Fourdan editbugs 2006-01-13 17:42:26 CET
Yeap, that proves it's a panel bug. Jasper, I could try to dig in your code, but
you might be faster than me in this regard. BAsically, you need to take the
actual panel position when setting the struts, not just the height/width of the
panel.
Comment 13 Jasper Huijsmans editbugs 2006-01-14 18:19:54 CET
I'll take this bug. Thanks.

Comment 14 Jasper Huijsmans editbugs 2006-02-05 16:28:40 CET
Hmm, I have tried to fix this for te development version of Xfce in SVN. 

I don't think I will have time to fix it for the 4.2 branch as well, but I'll
leave the report open for now.
Comment 15 Jasper Huijsmans editbugs 2006-03-11 19:32:02 CET
(In reply to comment #14)
> Hmm, I have tried to fix this for te development version of Xfce in SVN. 
> 
> I don't think I will have time to fix it for the 4.2 branch as well, but I'll
> leave the report open for now.
> 

Note that there was an error in the implementation that should be fixed in
revision 20343.
Comment 16 Jasper Huijsmans editbugs 2006-08-01 18:36:34 CEST
Ok, it's fixed for 4.4 only. 

Bug #1316

Reported by:
Steven Robertson
Reported on: 2006-01-09
Last modified on: 2010-11-20

People

Assignee:
Nick Schermer
CC List:
1 user

Version

Version:
Unspecified

Attachments

Display current display and screen(s) size (826 bytes, text/plain)
2006-01-09 21:20 CET , Olivier Fourdan
no flags
Display current display, screen(s) and monitor(s) size(s) (1.07 KB, text/plain)
2006-01-10 11:45 CET , Olivier Fourdan
no flags
Screenshot (with captions) displaying problem. (541.58 KB, image/png)
2006-01-11 09:56 CET , Steven Robertson
no flags

Additional information