Bug 4802 - Window sizing problems with tint2
Status: ASSIGNED
Alias: None
Product: Openbox
Classification: Unclassified
Component: general
Version: 3.5.0
Hardware: PC Linux
: P1 normal
Assignee: Dana Jansens
QA Contact:
URL:
Depends on:
Blocks:
 
Reported: 2010-11-23 09:45 EST by joss-bugzilla@pseudonymity.net
Modified: 2014-11-05 01:44:48 EST
5 users (show)

See Also:



Description joss-bugzilla@pseudonymity.net 2010-11-23 09:45:22 EST
Setup: Gentoo with Openbox 3.4.11.2 and no desktop manager.

I'm having a strange problem with xrandr and openbox 3.4.11.2 on Gentoo. I generally run a dual monitor setup on an intel graphics chip. The system is a Thinkpad X201. 

There's an internal laptop display (1280x800) and an external monitor (1600x1200). My current setup is to have the external monitor directly above the internal monitor. (External is at position 0x0, internal is at position 160x1200.)

When I enable the external monitor, any windows created on the internal monitor seem to be assigned a height of 1 pixel (or maybe 0 pixels). The result is that an xterm created there is one character high; a gvim window is 1 character high plus window decorations. The width does not seem to be affected.

The same happens if I try to maximise windows on that screen; they get their height set to as small a value as as possible. I can move windows around that screen fine, and resize them as I like. It's just creating new windows and maximising existing windows that's a problem.

The problem doesn't happen if I set the internal screen to the side of the external one, or diagonally beneath it. It only seems to occur if the internal monitor is in any way vertically beneath the external monitor. (Internal monitor at position 1601x1200 is fine. 1599x1200 is not.)

I've tested with fluxbox to check that it's not simply an X problem, and doesn't seem to have any problems. I've made sure to try restarting Openbox after the reconfigure, reconfiguring it after the reconfigure. I've also run an xterm-only X session, resized the screens then run openbox once the screens are already at correct resolution and placement. All cause the same problem.

Steps to reproduce:

Setup: Thinkpad X201 with Intel integrated graphics. Internal monitor 1200x800, External 1600x1200.

1) With Openbox running*, use xrandr to resize and place monitors:

   xrandr --output VGA1 --mode 1600x1200
   xrandr --output VGA1 --pos 0x0
      
   xrandr --output LVDS1 --mode 1280x800
   xrandr --output LVDS1 --pos 160x1200

2) Move mouse pointer to internal monitor and create any window. Alternatively, move existing window to internal monitor and maximise it.
3) Window will have minimal height.

(* The same occurs even if openbox is run after the xrandr commands.)
Comment 1 joss-bugzilla@pseudonymity.net 2010-12-16 17:57:31 EST
I just sat down to dig into the cause of this, and it seems to be due to some sort of interaction between the tint2 taskbar and Openbox. I can confirm that this behaviour /doesn't/ appear when tint2 is not running.

The behaviour occurs when tint2 is running on the upper of the two screens; when I set tint2 to run on the bottom screen then windows maximize correctly. For the moment I would say that may not be a bug in Openbox itself, but I'll try and look into it more and work out where exactly the problem lies.
Comment 2 lx 2011-09-19 10:50:47 EDT
I have same issue.

Hardware configuration: notebook + external VGA. Using only VGA, laptop just closed.
Soft: Ubuntu 11.04 (without Gnome/KDE) + Openbox 3.4.11.2. And i have no tint2 in configuration.

Reproduce:

1. With resolution 1024x768 it's all ok.

2. xrandr --output VGA-0 --mode 1280x1024

3. Just open terminal and try to maximize => as result window is not fully maximized(partly)

3'. Open terminal and place it in the right down corner of the screen. Try to maximaze => work correctly.


(In reply to comment #0)
> Setup: Gentoo with Openbox 3.4.11.2 and no desktop manager.
> 
> I'm having a strange problem with xrandr and openbox 3.4.11.2 on Gentoo. I
> generally run a dual monitor setup on an intel graphics chip. The system is a
> Thinkpad X201. 
> 
> There's an internal laptop display (1280x800) and an external monitor
> (1600x1200). My current setup is to have the external monitor directly above
> the internal monitor. (External is at position 0x0, internal is at position
> 160x1200.)
> 
> When I enable the external monitor, any windows created on the internal monitor
> seem to be assigned a height of 1 pixel (or maybe 0 pixels). The result is that
> an xterm created there is one character high; a gvim window is 1 character high
> plus window decorations. The width does not seem to be affected.
> 
> The same happens if I try to maximise windows on that screen; they get their
> height set to as small a value as as possible. I can move windows around that
> screen fine, and resize them as I like. It's just creating new windows and
> maximising existing windows that's a problem.
> 
> The problem doesn't happen if I set the internal screen to the side of the
> external one, or diagonally beneath it. It only seems to occur if the internal
> monitor is in any way vertically beneath the external monitor. (Internal
> monitor at position 1601x1200 is fine. 1599x1200 is not.)
> 
> I've tested with fluxbox to check that it's not simply an X problem, and
> doesn't seem to have any problems. I've made sure to try restarting Openbox
> after the reconfigure, reconfiguring it after the reconfigure. I've also run an
> xterm-only X session, resized the screens then run openbox once the screens are
> already at correct resolution and placement. All cause the same problem.
> 
> Steps to reproduce:
> 
> Setup: Thinkpad X201 with Intel integrated graphics. Internal monitor 1200x800,
> External 1600x1200.
> 
> 1) With Openbox running*, use xrandr to resize and place monitors:
> 
>    xrandr --output VGA1 --mode 1600x1200
>    xrandr --output VGA1 --pos 0x0
> 
>    xrandr --output LVDS1 --mode 1280x800
>    xrandr --output LVDS1 --pos 160x1200
> 
> 2) Move mouse pointer to internal monitor and create any window. Alternatively,
> move existing window to internal monitor and maximise it.
> 3) Window will have minimal height.
> 
> (* The same occurs even if openbox is run after the xrandr commands.)
Comment 3 Dana Jansens 2011-09-19 18:29:53 EDT
Would you mind verifying if the problem occurs in 3.5.0?
Comment 4 lx 2011-09-20 07:04:29 EDT
(In reply to comment #3)
> Would you mind verifying if the problem occurs in 3.5.0?

Hi, i try it today on 3.5.0. And had same behavior.

Additionally i make another observation - window switcher on Alt-Tab positioned after change mode(resolution) not in the center of the screen but in the center of place on which windows not fully maximized.
Comment 5 Dana Jansens 2011-10-15 17:44:09 EDT
*** Bug 4640 has been marked as a duplicate of this bug. ***
Comment 6 Dana Jansens 2011-10-15 23:12:43 EDT
@lx I think you are having a different problem than @joss.

i was able to reproduce the @lx problem, and understand it.  when cloning a desktop across multiple monitors openbox was very bad at choosing the correct monitor.  now it makes better use of hints from xrandr (use --primary), and you can also override that with the openbox config if you should so choose, but changing the primary monitor there (less desirable).

Relevant commits:
http://git.openbox.org/?p=dana/openbox.git;a=commit;h=3882bac2fbc9f7b839f93e2c4aa7e5cca9c9167a
http://git.openbox.org/?p=dana/openbox.git;a=commit;h=ea382ba7476144de0d67861dd97a241d01002c06
http://git.openbox.org/?p=dana/openbox.git;a=commit;h=44dbb3d235a66a86c48e3d69235b3462961f314a

@joss, i have not been able to reproduce this one yet I will try again tomorrow.  i didn't have tint2 set up just the right way it seems when i read through this again.
Comment 7 joss-bugzilla@pseudonymity.net 2011-10-16 03:36:29 EDT
Hello,

I just tested this setup again, although my current setup uses HDMI1 instead of VGA1; it's the same monitor and laptop, just with a digital rather than analogue connection.

Windows created on the 1280x800 internal screen now appear with the correct size, although their top edge is aligned with the top edge of that monitor. 

On maximizing, windows seem momentarily to have minimial height on the internal monitor, for a fraction of a second, then appear maximized on the other (external) monitor.
Comment 8 Jaroslav Smid 2012-01-10 15:19:48 EST
(In reply to comment #7)

Hello, in one of your earlier comments you said you were running tint2 on your upper screen. Your screen setup was like this, if I got it right:
___________________
|                 |
|                 |
|                 |
|=================|
  |             |
  |             |
  |_____________|

The === part represents the panel. Panel has to set _NET_WM_STRUT and/or _NET_WM_STRUT_PARTIAL (http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html) to reserve space on the edge of the SCREEN, not on the monitor, that is it had to set bottom part of that strut to 800+panel_height, thus making _NET_WORKAREA (http://standards.freedesktop.org/wm-spec/1.3/ar01s03.html) to be
{
  left = 0
  top = 0
  width = 1600
  height = 1200 - panel_height
}
Your bottom monitor is no longer included in work area, from which openbox behaved that way.

This is limitation of _NET_WM_STRUT_PARTIAL and there is not simple way around this unless WM ignores those boundaries and limits them by monitor geometry somehow (I actually think openbox should be little bit smarter and check window size that set _NET_WM_STRUT_PARTIAL on itself if it actually is that large or not, set workarea the way standard wants it, but ignore it during maximization and do it by it's own way).

What would help is placing your panel either on the top of your top monitor or on bottom of your bottom monitor.
Comment 9 Alexander 2013-05-02 13:45:12 EDT
There is bug appeared after upgrading from Ubuntu 12.10 to 13.04.

Now when I boot up with small resolution, and then change it with lxrandr to bigger, i see, that on hide-restore action my maximized window size is toggling between old and new resolution.

Here is what happens:
http://senya.dyndns-at-home.com/out.ogv
Comment 10 Mikachu 2014-11-05 01:44:48 EST
Possibly related to bug 4332