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!
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.
Created attachment 389 Display current display and screen(s) size Can you compile and run the attached test program and post the result?
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.
> 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.
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.
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.
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.
Oh, and I forgot, what xfce/xfwm4 version is it (try xfwm4 --version)?
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.
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.
_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.
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.
I'll take this bug. Thanks.
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.
(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.
Ok, it's fixed for 4.4 only.