Bug 3792 - Struts and Partial Struts are broken on Xinerama with monitors having different resolutions
Status: CLOSED FIXED
Alias: None
Product: Openbox
Classification: Unclassified
Component: general
Version: 3.4.7.2
Hardware: PC Linux
: P3 normal
Assignee: Dana Jansens
QA Contact:
URL:
: 3773
Depends on:
Blocks:
 
Reported: 2008-10-03 00:35 EDT by dynamotwain
Modified: 2009-12-16 17:04:27 EST
3 users (show)

See Also:

Attachments
Fix interpretation of struts for workarea and window maximization purposes (2.70 KB, patch)
2008-10-03 03:02 EDT, dynamotwain

Description dynamotwain 2008-10-03 00:35:26 EDT 
According to the WM Specification, the left, top, right, and bottom fields are to be declared relative to the overall X screen dimensions, not the monitor dimensions.

The example given in the spec (v1.3 or 1.4draft2) is: "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. Note that the strut is relative to the screen edge, and not the edge of the xinerama monitor."

In my case, I have a 1680x1050 monitor to the left of a 1920x1200 monitor aligned at the top. I then have a gnome-panel along the bottom edge of the 1680x1050 monitor with a height of 24 pixels.

xprop reports the following partial strut:
_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 175, 0, 0, 0, 0, 0, 0, 0, 1679
which is correct according to the spec. Gnome-panel is reserving the 150 pixels along the bottom that aren't visible on the screen plus the 25 it requests for itself.

However, maximizing a window on this monitor leaves a gap of exactly 150 pixels between the bottom edge of the maximized window and the top edge of the panel.
Comment 1 dynamotwain 2008-10-03 00:55:06 EDT 
Also, when the 1680x1050 monitor is the primary monitor (id=1) then the _NET_WORKAREA property on the root window is also off by 150px for the same reason.
Comment 2 dynamotwain 2008-10-03 03:02:19 EDT 
Created attachment 1879 [details]
Fix interpretation of struts for workarea and window maximization purposes

This patch fixes the two issues I mentioned for exterior monitor edges.
It doesn't attempt to account for "interior" monitor edges (i.e. a 'left' strut on monitor A when monitor B is directly to the left of monitor A) because it's not possible to do so with the current strut specification (see http://mail.gnome.org/archives/wm-spec-list/2004-March/msg00004.html for a discussion on this limitation)

This could be avoided by having the partial strut atom contain a xinerama screen ID that the strut applies to, but unfortunately the discussion all those years ago never got anywhere.
Comment 3 Mikachu 2009-07-04 12:54:49 EDT 
Is this the same problem as in bug #3773? (but with a better patch)
Comment 4 dynamotwain 2009-07-05 06:51:33 EDT 
Bug 3922 is definitely describing the same issue, and the description that Lucas and wd experienced in Bug 3373 is also the same issue; however, Richard's patch in 3373 is addressing a completely separate issue that might not even be an Openbox issue.

It's been a while since I've looked at this code, but I didn't see any off-by-one bugs when I wrote my patch, and I gave it a fairly thorough examination as I hadn't yet isolated the issue. RANGES_INTERSECT itself is valid when passed appropriate starting elements and lengths/widths; in addition, the pattern of "width = end - start + 1" is correct. The STRUTS_*_IN_SEARCH are correct as they are, *without* Richard's patch. His (Richard's) screenshot and description detail a setup in which the monitor's top edges are aligned (i.e. monitor_top[0] == monitor_top[1] == screen_top == 0) and a strut is placed along the top edge, whereas this issue is when a dock is placed along non-aligned edges. My conclusion bug 3373's patch is incorrect and also completely fails to address this issue (wd's results support my conclusion).

I don't recognize the clock app in Richard's screenshot, but I find it very likely that the clock app is reporting a strut that's 1 pixel too wide (i.e. end_x = window_width or end_x = window_x + window_width instead of end_x = window_x + window_width - 1). Such a mistake wouldn't be noticed unless the dock was placed on a monitor left of the rightmost monitor in a Xinerama setup. 

Bug 3373's patch addresses the error Richard experienced by avoiding the fault (by *adding* what I believe to be an off-by-one issue) without addressing the underlying failure. Unfortunately, he doesn't list monitor resolutions and positions, nor the _NET_WM_STRUT_PARTIAL property for his strut, so there is no way to identify whether the problem is truly Openbox's failing or if instead it should be the dock app that is to be blamed.
Comment 5 Mikachu 2009-07-05 06:57:39 EDT 
*** Bug 3773 has been marked as a duplicate of this bug. ***
Comment 6 Mikachu 2009-07-05 07:27:29 EDT 
Thank you for your detailed analysis, I have committed this patch as it didn't seem to break my non-xinerama setup :).
Comment 7 wd 2009-10-12 01:20:58 EDT 
This bug also exists in KDE 4.3.2 and openbox 3.4.8_rc1.

I tried the patch, it worked. I can max a window in the small desktop. 

But this patch add an other bug.
In openbox + tint2, when I max a window in the small desktop, the window will convers tint2.
Comment 8 dynamotwain 2009-10-12 03:40:02 EDT 
(In reply to comment #7)
> But this patch add an other bug.
> In openbox + tint2, when I max a window in the small desktop, the window will
> convers tint2.

Openbox is not responsible for the behavior of broken applications. The reason Openbox will cover your tint2 panels is that tint2 does not comply with the portion of wm-spec regarding _NET_WM_STRUT and _NET_WM_STRUT_PARTIAL which explicitly states that strut boundaries must be specified relative to the X screen (not monitor) boundaries. tint2 specifies struts relative to monitor boundaries, which not permitted by the standard.

Specifically, I am referring to the following sentence in http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html: "The start and end values associated with each strut allow areas to be reserved which do not span the entire width or height of the screen. Struts MUST be specified in root window coordinates, that is, they are not relative to the edges of any view port or Xinerama monitor."

If you wish this behavior fixed, the proper course of action would be to file a bug with tint2 and not Openbox.
Comment 9 wd 2009-10-12 23:16:07 EDT 
I don't understand the tech reason why this happen. I only can show you what's happen.

This is openbox in kde. It's worked perfect.
http://paste.ubuntu.org.cn/i45596

This is openbox + tint2. It's worked before The patch.
http://paste.ubuntu.org.cn/i45597

This is an other pic for openbox+tint2.
http://paste.ubuntu.org.cn/i45598
Comment 10 wd 2009-10-12 23:17:53 EDT 
I don't understand the tech reason why this happen. I only can show you what's happen.

This is openbox in kde. It's worked perfect.
http://paste.ubuntu.org.cn/i45596

This is openbox + tint2. It's worked before The patch.
http://paste.ubuntu.org.cn/i45597

This is an other pic for openbox+tint2.
http://paste.ubuntu.org.cn/i45598
Comment 11 Dana Jansens 2009-12-16 17:04:27 EST 
closing this, the patch was correct, thank you.

@wd tint2 needs to be corrected, it was relying on openbox's non-standard behaviour.