Wrong windows maximization in multimonitor, multiscreen configuration.

[ic-kashey]

I have set-up following configuration with TWO X-screens and THREE physical monitors:

DISPLAY=:0.0 Monitor 1: 1920x1200 at 0,0 Monitor 2: 1600x1200 at 1920,0

DISPLAY=:0.1 Monitor 3: 1920x1200 at 0,0

All window on screen 0 maximized across both monitors, i.e. becomes 3520x1200

But without second X-screen window maximization is correct, to 1920x1200 at 0,0 or 1600x1200 at 1920,0 depending on current monitor.

I write small test program, that calls gdk_screen_get_monitor_at_point() / get_monitor_geometry() and I can see correct monitor layout:

export DISPLAY=:0.0

./test 10 10 Position: X=10, Y=10. Monitor: 0 Geometry: 1920x1200+0+0 Plug: DFP6

./test 2010 10 Position: X=2010, Y=10. Monitor: 1 Geometry: 1600x1200+1920+0 Plug: CRT1

export DISPLAY=:0.1

./test 10 10 Position: X=10, Y=10. Monitor: 0 Geometry: 1920x1200+0+0 Plug: DFP1

Fedora 16, marco-1.4.1-0102.fc16.x86_64 installed from repository.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/2121213-wrong-windows-maximization-in-multimonitor-multiscreen-configuration?utm_campaign=plugin&utm_content=tracker%2F841233&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F841233&utm_medium=issues&utm_source=github).

[discordier]

Same problem for me. Is there any update on this?

Interesting fact: the panels only stretch to the width of the Monitor they reside on. Just the windows maximize over all Monitors in the current display.

[ic-kashey]

Not only panels. Tooltips too. But while panels is not a part of marco, tooltips is a part.

$ cd build/mate-desktop-mate-window-manager/src $ find . -type f | xargs grep grep get_monitor_geometry ./ui/fixedtip.c: gdk_screen_get_monitor_geometry (gdk_screen, mon_num, &monitor);

Tooltips works fine, try to hold mouse pointer over close button near monitor edge.

But there is only one match. So, window placement code use another, unknown functions. Seems like bad code located inside core/screen.c, but I can not find correct place in few minutes, need to spent more time, read mans, run debug etc. I still hope :), author will fix it (or at least explain).

[discordier]

My quick code screening show that marco is only evaluating the Xinerama information, if available which is not the case for me. Therefore multi screens will not be evaluated.

I wonder how this could have been working in nautilus as the code in there is the same. I found some changes in Ubuntu repos for unity which seem to address this issue and seem to query the X server layout from libX while searching the net.

I wonder what libs marco is "allowed" to be linked against as this is important to be able to fix this. I think one could "fake" the Xinerama info by querying gdk, if no Xinerama is available using

• gdk_screen_get_n_monitors()
• gdk_screen_get_monitor_geometry()

etc.

[discordier]

Another update on this one. I just realized, that when resizing via holding SHIFT, marco correctly snaps the window to monitor borders. also when moving a window towards the edge of a monitor, the snapping is correctly (using the 10px or whatever magnet band).

so this really only affects maximizing windows.

[stefano-k]

@ic-kashey @discordier did you try with another window manager? like mutter or metacity?

[stefano-k]

Could you try to apply this patch https://github.com/albertsmuktupavels/metacity/commit/55d03330a6635314f91041806e2bf2f2c1fae259 ?

[discordier]

I will have to try to compile it as package. Will do so but it will take some time as I am rather busy at the moment.

[mikebutash]

I get this issue occurring on just about every desktop manager/compositor actually, rather annoying as I use 5 or 6 displays at a time. This is done using a giant framebuffer with ati fglrx eyefiniti support. Under compiz, I have to hard set the framebuffer size in general settings, disabling monitor discovery or it treats them as individual framebuffers too. Even then, compiz can't handle that size of framebuffer without crapping the bed though.

Weird part is with compositing enabled with marco/mate and trying to do this with a gl-based game/app, if it does snap to, it leaves an overlay permanent ghost of the last image across the monitors I have the display stretched across. This is kind of annoying, wiping another window across the ghost wipes it clean for normal rendering behind it. Using 1.8.0+dfsg1-3~ppa1~trusty1.

[lucasmr]

Still experiencing this on mate 1.12 and 1.14. Any hopes of fixing without using xinerama?

To reproduce: get 2 monitors extending desktop, maximize a window. The window will now span both monitors.

[discordier]

I am not experiencing it anymore in 1.12.1.

[lucasmr]

Tested x11-wm/marco-1.12.1 on gentoo with USE=-xinerama and the problem persists. Using +xinerama fixes it, but is there a way to fix without it?

[crazyfwed]

I also have the issue on gentoo using marco-1.18.2 (without xinerama)

[allanlaal]

same issue on Ubuntu 20.04 LTS with marco-1.24.0-1 (without xinerama afaik and without software compositioning and without compiz)

this happens even when I xrandr to my main laptop display only (X screen size = display size)

in my case more often the horizontal size of maximized windows matches the display horizontal size, but the vertical will use panel size - top panel, but will hide behind the bottom panel (autohide off on both) -- this happens randomly after every reboot as far as I can see I've had the issue where a maximized window will span all 3 monitors though (a complete reboot has solved it usually)