support multi-head configurations better - fix fullscreen?

[totaam]

Issue migrated from trac ticket # 496

component: server | priority: minor | resolution: fixed

2014-01-15 08:40:27: totaam created the issue

---

There is a problems with the flash player (and probably other apps) that try to detect the hardware configuration when going fullscreen: it goes fullscreen server-side (using all available space), but it may only go fullscreen on one of the monitors client side...
Note: the HTML5 player in chrome does not have this problem.

Having a quick play with xrandr, although it is possible for us to declare more than one dummy videocard, we need xinerama to be able to paint to both virtual screens simultaneously... which disables xrandr, so pretty useless unless we can create the exact xorg.conf matching the client, and before launching xpra.
See RandR and Xinerama

I don't think dummy should support multiple virtual screens (too complicated), but maybe we should be able to tweak its xinerama data (and see also dpi #163)

Related to #56 and #33

[totaam]

2014-01-31 10:41:17: antoine changed status from new to assigned

[totaam]

2014-01-31 10:41:17: antoine commented

---

Seems to be working for me with r5323.
Note: this requires installing libfakeXinerama.so.1 (modified source which we now keep here: [/browser/xpra/trunk/src/fakexinerama fakexinerama]) somewhere that the code will find (ie: /usr/lib64 or /usr/lib for now), and the application must be started using --start-child=

Remaining issues:

• packaging libfakeXinerama, at least for the RPM distros
• had a case where the new monitor was not propagated to the file when I plugged it in
• honour LD_LIBRARY_PATH for lookup
• improving the library so it will read the configuration file again if it is modified (as it will be when a new client connects - or if we start the application before the client connects)

For the record, here's what my laptop reports with a secondary screen attached:

root size is 3286x1080 with 1 screen(s):
  ':0.0' 3286x1080 (869x286 mm) workarea: 3286x743 at 0x0
    'LVDS1' 1366x768 at 0x0 (344x193 mm)
    'HDMI1' 1920x1080 at 1366x0 (531x299 mm)

And this is the file the new code generates for this setup:

# 2 monitors:
2
# LVDS1 (344mm x 193mm)
0 0 1366 768
# HDMI1 (531mm x 299mm)
1366 0 1920 1080

[totaam]

2014-01-31 21:49:45: smo commented

---

Tested with windows 7 client with r5323 server on fedora 19. No errors and here is the output from xpra and .fakexinerama.

Installed compiled shared library for libfakexinerama in /usr/lib64/

Some attachments of screenshots of what we are seeing to follow.

2014-01-31 13:23:18,792 Python/Gtk2 Microsoft Windows 7 client version 0.12.0 connected from 'Maxmylyn-PC' as 'Maxmylyn' ('Maxmylyn')
2014-01-31 13:23:18,793 using h264 as primary encoding, also available: vp8, png, png/P, png/L, rgb24, jpeg, webp
2014-01-31 13:23:18,793 root size is 3200x900 with 1 screen(s):
2014-01-31 13:23:18,793   '1\WinSta-Default' 3200x900 (846x238 mm) workarea: 3200x900 at 0x0
2014-01-31 13:23:18,793     'DISPLAY1' 1600x900 at 0x0 (564x318 mm)
2014-01-31 13:23:18,793     'DISPLAY2' 1600x900 at 1600x0 (564x318 mm)
2014-01-31 13:23:18,794 maximum client resolution is 3200x900 (current server resolution is 3840x1080)

# 2 monitors:
2
# \\.\DISPLAY1 (564mm x 318mm)
0 0 1600 900
# \\.\DISPLAY2 (564mm x 318mm)
1600 0 1600 900

[totaam]

2014-01-31 22:06:26: afarr commented

---

Also tested with osx (mavericks) and r5323

A quick xpra info | grep client.screen output the following:

client.screen[0].display=spikess-macbook-pro.local
client.screen[0].monitor[0].geometry=(0, 0, 1440, 900)
client.screen[0].monitor[0].name=
client.screen[0].monitor[0].size_mm=(508, 317)
client.screen[0].monitor[1].geometry=(1440, 0, 2560, 1440)
client.screen[0].monitor[1].name=
client.screen[0].monitor[1].size_mm=(903, 508)
client.screen[0].size=(4000, 1440)
client.screen[0].size_mm=(1411, 508)
client.screen[0].workarea=(0, 0, 4000, 1440)
client.screens=1

Some hand picked bits from a xpra info | grep window:

window[3].focused=False
window[3].fullscreen=True

window[3].position=(0, 0)
window[3].property.fullscreen=True

• With --start-child=xterm followed by launching chrome from the xterm, fullscreen on the monitor (client.screen[0].monitor[0]) worked as expected, but on the other monitor it displayed half-way across the larger monitor (screenshots to follow).

• With --start-child=google-chrome or --start-child=firefox however, the same half-screen of one monitor display recurred.

(Is it perhaps an idea to have the window[].position correlate to then decide which client.screen[].monitor[] the window with focus is on and then use the corresponding geometry to set fullscreen size and location?)

[totaam]

2014-01-31 22:07:51: afarr uploaded file large-monitor-display_start-child-chrome_fullscreen.png (383.6 KiB)

the display of fullscreen chrome on larger monitor (start-child chrome)

[totaam]

2014-01-31 22:08:33: afarr uploaded file large-monitor-display_start-child-firefox_fullscreen.png (1132.5 KiB)

the display of fullscreen on large monitor (start-child firefox)

[totaam]

2014-01-31 22:10:05: afarr uploaded file laptop-screen-display_start-child-chrome_fullscreen.png (1524.0 KiB)

the (lack of) display of fullscreen on smaller (laptop) monitor (start-child firefox or chrome)

[totaam]

2014-02-01 00:42:52: totaam commented

---

Aren't those the same problems as before? Are the problems only on OSX or also on win32? If so, you can skip the section below on libfakeXinerama debugging.
(It's not entirely clear to me what the screenshots are meant to show. As in, what was done to get there, what buttons or keys were pressed, and what the browser window should contain - a static test video would make this clearer)
Assuming that the problems are also occurring on win32:

• please post: ls -la /usr/lib/libfake*
• try building the library as of r5326 or later with "#define DEBUG" not commented out: every time the library is called, you should see the message printed on the terminal were you start the application that uses it (ie: in the xterm if you start firefox from there).

---

The report that things work on the first monitor when launched from the xterm but not from start-child does not make sense (edit: never mind - it does make sense, see comment:5). Again, is this on all platforms? Does it not work with virtualbox, as it did for me?

You should be able to see the preload from the xterm with:

env | grep LD_PRELOAD

Perhaps you're not using a clean new session each time, and then you are hitting the remaining issues noted in comment:1 ?

Notes for debugging:

• even if you are certain that you never have multiple sessions for the same user, please always post the .$DISPLAY-fakexinerama file and not the .fakexinerama fallback
• please include xpra info data as per comment:3
• please try [/browser/xpra/trunk/src/tests/xpra/test_apps/test_window_maximize.py test_window_maximize.py] native (without using xpra) and see if it does fullscreen properly. If not, then we may have a toolkit problem.

[totaam]

2014-02-01 06:53:58: totaam commented

---

Most of the remaining issues (bar OSX) are fixed in r5325 and r5326. I have built RPM packages for libfakeXinerama using the specfile in r5327 - available in the beta area.

I am unable to test multi-monitor OSX in virtualbox as the non-primary screens aren't recognized.

Further testing with triple monitor setups in virtualbox:

• XP Pro 64-bit (I did get an xpra crash once moving a window across the virtual monitors..)

root size is 2516x670 with 1 screen(s):
  'WinSta-Default' 2516x670 (665x177 mm) workarea: 2516x670 at 0x0
    'DISPLAY1' 916x670 at 0x0 (320x240 mm)
    'DISPLAY2' 800x600 at 916x0 (320x240 mm)
    'DISPLAY3' 800x600 at 1716x0 (320x240 mm)

• Windows Vista:

Python/Gtk2 Microsoft Windows Vista client version 0.11.2 connected from 'Vista-PC' as 'Vista' ('Vista')
using h264 as primary encoding, also available: vp8, png, png/P, png/L, rgb24, jpeg, webp
root size is 2752x864 with 1 screen(s):
  '1\WinSta-Default' 2752x864 (728x228 mm) workarea: 2752x864 at 0x0
    'DISPLAY1' 1152x864 at 0x0 (320x240 mm)
    'DISPLAY2' 800x600 at 1152x0 (320x240 mm)
    'DISPLAY3' 800x600 at 1952x0 (320x240 mm)

• Windows 8:

Python/Gtk2 Microsoft Windows 8 client version 0.11.2 connected from 'Windows8' as 'win8' ('win8')
using h264 as primary encoding, also available: vp8, png, png/P, png/L, rgb24, jpeg, webp
root size is 3072x768 with 1 screen(s):
  '1\WinSta-Default' 3072x768 (812x203 mm) workarea: 3072x768 at 0x0
    'DISPLAY1' 1024x768 at 0x0 (271x203 mm)
    'DISPLAY2' 1024x768 at 1024x0 (271x203 mm)
    'DISPLAY3' 1024x768 at 2048x0 (271x203 mm)

Worked fine in all cases with both Firefox and Chrome.
The window's attributes, position and dimensions are correct, ie: here Firefox flash plugin running fullscreen on the third monitor fullscreen:

window[67].title=plugin-container
window[67].fullscreen=True
window[67].property.fullscreen=True
window[67].position=(1716, 0)
window[67].size=(800, 600)

Note: as of r5330 + r5334, we force a RandR re-set, even when the new virtual display dimension is identical to the previous one, this is usually enough to force application to re-query Xinerama and get the updated virtual screen dimensions. What this means is that fullscreen should now work even when the application initializes Xinerama before the client attaches - as long as libfakeXinerama is preloaded obviously.

[totaam]

2014-02-01 07:51:45: totaam changed status from assigned to new

[totaam]

2014-02-01 07:51:45: totaam changed owner from antoine to afarr

[totaam]

2014-02-01 07:51:45: totaam commented

---

I can't see anything left for me to do. I have summarized all the information on the wiki: FakeXinerama

Please test as per comment:4 and comment:5.

[totaam]

2014-02-04 23:22:09: afarr commented

---

Ok, testing r 5343 with a windows 7 desktop with two external monitors, all looks delightful. Also testing with different apparent display sizes, all looked delightful.

Testing in osx r5343, with a laptop with an attached external monitor, however, the behavior became exrtremely erratic. (Note, I don't think this is an osx vs. win issue - I think it is a laptop display vs. external monitor behavior issue. Earlier testing with a windows 7 laptop with attached external monitor also seemed to display erratic behavior.)

As for the behavior that I observed with the osx laptop and attached external monitor, I'll summarize and include a lot of screenshots to hopefully make the behavior comprehensible (as comprehensible as it can be).

(Note also, when I went to the Xpra.app/Contents/Resources/python2.7 directory of the local osx xpra to try to run test_window_maximize.py I got the following errors:

spikess-MacBook-Pro:python2.7 spikes$ python test_window_maximize.py
Traceback (most recent call last):
  File "test_window_maximize.py", line 3, in <module>
    import gtk
  File "gtk/__init__.pyc", line 30, in <module>
    
  File "gobject/__init__.pyc", line 26, in <module>
    >
  File "glib/__init__.pyc", line 22, in <module>
    
  File "glib/_glib.pyc", line 14, in <module>
    
  File "glib/_glib.pyc", line 13, in __load
    
ImportError: 'glib/_glib.so' not found

... not sure if I was in the wrong directory to use the python shell, or if the file I copied into that directory wasn't formatted correctly... or what.)

Anyway, the laptop results:

• With laptop display left of external monitor… xpra window on laptop display… fullscreen behaves as expected (fullscreen on laptop display).

• With laptop display left of external monitor… xpra window on external monitor… fullscreen displays over just shy of half external monitor screen.

• Client-side monitor info:

2014-02-04 14:39:03,842 root size is 4000x1440 with 1 screen(s):
2014-02-04 14:39:03,843   'spikess-macbook-pro.local' 4000x1440 (1411x508 mm) workarea: 4000x1440 at 0x0
2014-02-04 14:39:03,843     'monitor 1' 1440x900 at 0x0 (508x317 mm)
2014-02-04 14:39:03,843     'monitor 2' 2560x1440 at 1440x0 (903x508 mm)

Exit server and client xpra sessions. Set Displays with external monitor left of laptop display. Restart.

• With external monitor set left of laptop display, xpra window on laptop display, fullscreen causes xpra window to move to and display on external monitor- at fullscreen-size expected for the (smaller) laptop display. (Nothing of xpra window displays on the laptop display where it was when fullscreen button was clicked.)

• With external monitor set left of laptop display, xpra window on external monitor, fullscreen works as expected.

Exit server and client session. Set Displays with laptop display above external monitor. Restart.

• With laptop display set above external monitor, xpra window on laptop display, fullscreen displays across about 2/3 of laptop display screen.

• With laptop display set above external monitor, xpra window on external monitor, fullscreen behaves as expected.

[totaam]

2014-02-04 23:23:40: afarr uploaded file display_layout-laptop_left_of_external.png (57.8 KiB)

the layout for first two tests of comment 6 - laptop display left of external monitor

[totaam]

2014-02-04 23:25:44: afarr uploaded file fullscreen-laptop_display-laptop_display_set_left_of_external.png (857.3 KiB)

first test of comment 6 - fullscreen on laptop display _ laptop display set left of external

[totaam]

2014-02-04 23:27:18: afarr uploaded file fullscreen-external_monitor-laptop_display_set_left_of_external.png (1755.9 KiB)

test 2 of comment 6 - fullscreen on external _ laptop display set left of external

[totaam]

2014-02-04 23:28:19: afarr uploaded file display_layout-external_monitor_left_of_laptop_display.png (52.7 KiB)

layout display second round of tests, comment 6 - external monitor set left of laptop display

[totaam]

2014-02-04 23:30:22: afarr uploaded file fullscreen-laptop_display-external_display set_left_of_laptop_display-_image_displayed_on_wrong_monitor.png (1652.4 KiB)

first of second round of tests, comment 6 - fullscreen of laptop display _ external display set left of laptop (nothing displayed on laptop screen)

[totaam]

2014-02-04 23:32:31: afarr uploaded file fullscreen_on_laptop_display-displays_instead_laptop_display_sized_on_external_monitor-external_display_set_left_of_laptop_display.png (2182.6 KiB)

also first test of second round, comment 6 - fullscreen clicked on laptop, laptop-sized display instead shows on external monitor _ external monitor set left of laptop display

[totaam]

2014-02-04 23:34:06: afarr uploaded file fullscreen_on_external-displays_as_expected-external_set_left_of_laptop_display.png (2997.2 KiB)

secvond test of second round, comment 6 - fullscreen on external monitor displays as expected (for completeness) _ external monitor set left of laptop display

[totaam]

2014-02-04 23:36:19: afarr uploaded file fullscreen-laptop_display-laptop_display_set_above_external_monitor.png (1460.4 KiB)

first test of third round, comment 6 - fullscreen on laptop display _ laptop display set above external monitor

[totaam]

2014-02-05 04:00:38: totaam commented

---

test_window_maximize.. I got the following errors..

You must run it from a jhbuild shell, or with the Python interpreter bundled in the Xpra.app (Xpra.app/Contents/Helpers/Python), not with the system python which knows nothing about gtk, glib, etc..

[[BR]]

As per comment:4, please include for all layouts tested:

• the .$DISPLAY-fakexinerama file
• selected bits from xpra info
• client-side monitor info - and does this match the actual position used?

Please also confirm if the bug is OSX-specific, or laptop-specific. I don't see why connecting extra screens to a laptop instead of a desktop PC would make any difference, but know knows. Maybe some configurations expose one large fake monitor instead of the 2 real monitors we need to know about, or maybe the order is wrong?
Or maybe GTK has problems with fullscreen on OSX, as it seems to choose the wrong display in some cases?

[totaam]

2014-02-05 04:17:34: totaam commented

---

Re-uploading the images with a size we can actually use more easily.

Which makes me ask the question: why are all the sizes different, I don't think two of those screenshots have the same dimensions!? And why only a few of the screenshots have the two screens included? Or maybe none have and it's just the area that is not covered by the "fullscreen" player? What is on the other one? Confusing.

Here is something I can understand (assuming I've done it more or less right).
I don't have time to tidy this up any further but, the images should use standard sizes to make it clearer, and the screenshots should include both screens in one to make it easier, etc...
("first" and "second" are defined top to bottom or left to right)
||# Layout||=Results=||=Fullscreen attempt on first Screen=||=Fullscreen attempt on second Screen=||
|| [[Image(display_layout-laptop_left_of_external.2.png)]] ||OK / NOK|| [[Image(fullscreen-laptop_display-laptop_display_set_left_of_external.2.png)]] [[Image(placeholder_external.png)]]||[[Image(placeholder_laptop.png)]] [[Image(fullscreen-external_monitor-laptop_display_set_left_of_external.2.png)]]||
||[[Image(display_layout-external_monitor_left_of_laptop_display.2.png)]]|| OK / NOK ||[[Image(fullscreen_on_external-displays_as_expected-external_set_left_of_laptop_display.2.png)]][[Image(placeholder_laptop.png)]] || [[Image( laptop_fullscreen_right-displays_on_wrong_monitor.png)]][[Image(laptop_right-laptop_fullscreen-desktop-2.png)]] ||
||[[Image( display_layout-laptop_display_set_above_external_monitor-2.png​)]]||NOK / OK||[[Image(round_3-offset_fullscreen_on_upper_laptop_display.png)]][[Image(placeholder_external.png)]]||[[Image(placeholder_laptop.png)]][[Image(fullscreen-external_monitor-laptop_display_set_above_external_monitor.png​)]]||

[[br]]

||# Layout||# xpra info | grep client.screenclient.screen||# Fullscreen attempt on first xpra info | grep window||# Fullscreen attempt on second xpra info | grep window||
|| laptop left || [0].display=spikess-macbook-pro.local || window[1].fullscreen=False || window[1].fullscreen=False ||
|| (set up 1) || client.screen[0].monitor[0].geometry=(0, 0, 1440, 900) || window[1].position=(1886, 72) || window[1].position=(574, 66) ||
|| || client.screen[0].monitor[0].name= || window[1].property.fullscreen=False || window[1].property.fullscreen=False ||
|| || client.screen[0].monitor[0].size_mm=(508, 317) || window[1].size=(499, 316) || window[1].size=(499, 316) ||
|| || client.screen[0].monitor[1].geometry=(1440, 0, 2560, 1440) || window[1].title=jimador@elpatron:~ || window[1].title=jimador@elpatron:~ ||
|| || client.screen[0].monitor[1].name= || window[2].fullscreen=True || window[2].fullscreen=True ||
|| || client.screen[0].monitor[1].size_mm=(903, 508) || window[2].position=(0, 0) || window[2].position=(0, 0) ||
|| || client.screen[0].size=(4000, 1440) || window[2].property.fullscreen=True || window[2].property.fullscreen=True ||
|| || client.screen[0].size_mm=(1411, 508) || window[2].size=(1440, 900) || window[2].size=(2560, 1440) ||
|| || client.screen[0].workarea=(0, 0, 4000, 1440) || window[2].title=Splendid by Professor Elemental - YouTube - Google Chrome || window[2].title=Splendid by Professor Elemental - YouTube - Google Chrome ||
|| || client.screens=1 || || ||

|| external left || [0].display=spikess-macbook-pro.local || window[1].fullscreen=False || window[1].fullscreen=False ||
|| (set up 2) || client.screen[0].monitor[0].geometry=(2560, 0, 1440, 900) || window[1].position=(2578, 58) || window[1].position=(1104, 1098) ||
|| || client.screen[0].monitor[0].name= || window[1].property.fullscreen=False || window[1].property.fullscreen=False ||
|| || client.screen[0].monitor[0].size_mm=(508, 317) || window[1].size=(499, 316) || window[1].size=(499, 316) ||
|| || client.screen[0].monitor[1].geometry=(0, 0, 2560, 1440) || window[1].title=jimador@elpatron:~ || window[1].title=jimador@elpatron:~ ||
|| || client.screen[0].monitor[1].name= || window[2].fullscreen=True || window[2].fullscreen=True ||
|| || client.screen[0].monitor[1].size_mm=(903, 508) || window[2].position=(0, 0) || window[2].position=(0, 0) ||
|| || client.screen[0].size=(4000, 1440) || window[2].property.fullscreen=True || window[2].property.fullscreen=True ||
|| || client.screen[0].size_mm=(1411, 508) || window[2].size=(2560, 1418) || window[2].size=(1440, 900) ||
|| || client.screen[0].workarea=(0, 0, 4000, 1440) || window[2].title=Splendid by Professor Elemental - YouTube - Google Chrome || window[2].title=Splendid by Professor Elemental - YouTube - Google Chrome ||
|| || client.screens=1 || || ||

|| laptop above || [0].display=spikess-macbook-pro.local || window[1].fullscreen=False || window[1].fullscreen=False ||
|| (set up 3) || client.screen[0].monitor[0].geometry=(503, 0, 1440, 900) || window[1].position=(863, 1062) || window[1].position=(1100, 183) ||
|| || client.screen[0].monitor[0].name= || window[1].property.fullscreen=False || window[1].property.fullscreen=False ||
|| || client.screen[0].monitor[0].size_mm=(508, 317) || window[1].size=(499, 316) || window[1].size=(499, 316) ||
|| || client.screen[0].monitor[1].geometry=(0, 900, 2560, 1440) || window[1].title=jimador@elpatron:~ || window[1].title=jimador@elpatron:~ ||
|| || client.screen[0].monitor[1].name= || window[2].fullscreen=True || window[2].fullscreen=True ||
|| || client.screen[0].monitor[1].size_mm=(903, 508) || window[2].position=(0, 0) || window[2].position=(0, 0) ||
|| || client.screen[0].size=(2560, 2340) || window[2].property.fullscreen=True || window[2].property.fullscreen=True ||
|| || client.screen[0].size_mm=(903, 825) || window[2].size=(1440, 900) || window[2].size=(2560, 1418) ||
|| || client.screen[0].workarea=(0, 0, 2560, 2340) || window[2].title=Splendid by Professor Elemental - YouTube - Google Chrome || window[2].title=Splendid by Professor Elemental - YouTube - Google Chrome ||
|| || client.screens=1 || || ||

[[br]]

Note: all screens represented by place holder (blue) screens displayed as expected (and weren't the monitors upon which an app's fullscreen option was clicked).

[[br]]

||# set up #||# client monitor output||# ~/.${DISPLAY}-fakexinerama||
|| set up 1 || 4000x1440 (1411x508 mm) || # 2 monitors: ||
|| || workarea: 4000x1440 at 0x0 || 2 ||
|| || 'monitor 1' 1440x900 at 0x0 (508x317 mm) || # monitor 0 (508mm x 317mm) ||
|| || 'monitor 2' 2560x1440 at 1440x0 (903x508 mm) || 0 0 1440 900 ||
|| || || # monitor 1 (903mm x 508mm) ||
|| || || 1440 0 2560 1440 ||
|| set up 2 || 4000x1440 (1411x508 mm) || # 2 monitors: ||
|| || workarea: 4000x1440 at 0x0 || 2 ||
|| || 'monitor 1' 1440x900 at 2560x0 (508x317 mm) || # monitor 0 (508mm x 317mm) ||
|| || 'monitor 2' 2560x1440 at 0x0 (903x508 mm) || 2560 0 1440 900 ||
|| || || # monitor 1 (903mm x 508mm) ||
|| || || 0 0 2560 1440 ||
|| set up 3 || 2560x2340 (903x825 mm) || # 2 monitors: ||
|| || workarea: 2560x2340 at 0x0 || 2 ||
|| || 'monitor 1' 1440x900 at 587x0 (508x317 mm) || # monitor 0 (508mm x 317mm) ||
|| || 'monitor 2' 2560x1440 at 0x900 (903x508 mm) || 587 0 1440 900 ||
|| || || # monitor 1 (903mm x 508mm) ||
|| || || 0 900 2560 1440 ||

[[br]]

[totaam]

2014-02-05 04:18:26: totaam uploaded file display_layout-laptop_left_of_external.2.png (0.5 KiB)

same as before, but chopped and resized

[totaam]

2014-02-05 04:18:53: totaam uploaded file display_layout-external_monitor_left_of_laptop_display.2.png (0.5 KiB)

same as before, but chopped and resized

[totaam]

2014-02-05 04:19:12: totaam uploaded file fullscreen_on_external-displays_as_expected-external_set_left_of_laptop_display.2.png (84.3 KiB)

same as before, but chopped and resized

[totaam]

2014-02-05 04:19:28: totaam uploaded file fullscreen-laptop_display-laptop_display_set_left_of_external.2.png (95.2 KiB)

same as before, but chopped and resized

[totaam]

2014-02-05 04:19:44: totaam uploaded file fullscreen-laptop_display-laptop_display_set_above_external_monitor.2.png (119.9 KiB)

same as before, but chopped and resized

[totaam]

2014-02-05 04:20:32: totaam uploaded file fullscreen-external_monitor-laptop_display_set_left_of_external.2.png (191.0 KiB)

[totaam]

2014-02-05 04:20:47: totaam uploaded file fullscreen-external_monitor-laptop_display_set_above_external_monitor.2.png (186.2 KiB)

same as before, but chopped and resized

[totaam]

2014-02-05 04:37:17: totaam uploaded file placeholder_laptop.png (0.8 KiB)

placeholder for missing screenshot of laptop screen

[totaam]

2014-02-05 04:37:34: totaam uploaded file placeholder_external.png (0.9 KiB)

placeholder for missing screenshot of external screen

[totaam]

2014-02-05 22:56:52: afarr uploaded file laptop_fullscreen_right-displays_on_wrong_monitor.png (90.4 KiB)

re-sized screenshot, fullscreen on laptop display, displays on wrong monitor

[totaam]

2014-02-05 23:25:12: afarr uploaded file round_3-offset_fullscreen_on_upper_laptop_display.png (145.5 KiB)

fullscreen on laptop display, when set above external monitor, displays askew

[totaam]

2014-02-05 23:59:09: afarr commented

---

It looks like you got the screenshots for the external-display:left/laptop-display:right scenario mixed up. The one you posted as being the external was actually the laptop display desktop (upon which desktop the chrome window was when fullscreen was clicked, but in that case the fullscreen jumped to the external monitor to display at full-(laptop)-screen size, while the laptop desktop became vacant.

I attached an easier to work with size copy of the screenshot of the external monitor to go with that screenshot of the laptop desktop, called it laptop_fullscreen_right-displays_on_wrong_monitor.png.

In the final case, rather than try to format after having tried to meticulously collect xpra info, I'll try to be concise.

Fullscreen on the laptop display (when set "above" the external) displays as seen in the other newly uploaded cropped screenshot: round_3-offset_fullscreen_on_upper_display.png. With this display configuration (laptop display above), fullscreen on the external monitor displays as expected.

I'll also attach a text file with all that xpra info.

Meanwhile, I still can't seem to get test_window_maximize.py to run. I continue to get a missing gtk error.

spikess-MacBook-Pro:Helpers spikes$ pwd
/Users/spikes/Desktop/xpra-dists/xpra5343/Xpra.app/Contents/Helpers
spikess-MacBook-Pro:Helpers spikes$ ls
Keyboard_Tool		SSH_ASKPASS		gst-plugin-scanner
Python			Xpra			test_window_maximize.py
spikess-MacBook-Pro:Helpers spikes$ Python test_window_maximize.py 
Traceback (most recent call last):
  File "test_window_maximize.py", line 3, in <module>
    import gtk
ImportError: No module named gtk

Is there some other directory I should move test_window_maximize.py to in order for it to find gtk? (I tried with it in the python2.7 folder as well, at which point the Python just told me there was no such file as test_window_maximize.py.)

[totaam]

2014-02-06 00:38:31: totaam commented

---

Please spend a bit of time presenting your data. I've spent almost an hour trying to reformat it last time around (comment:9). And you're saying I got some of it wrong... then please help me with it.

Dumping large text files (900 lines) in the ticket is not it. Please understand the difference between seeing comment:9 (or something like it), and having to dig through 26 attachments on a single ticket. The xpra info was trimmed in comment:3, the one in this latest attachment isn't. It is also very hard to figure out what the data means since it does not include the monitor dimensions next to it. Those can be inferred, but things are already hard enough. Then I have to know which screenshots match that data?? Too hard.

As for the the Python interpreter to use, as per comment:8, you should use the full path to the interpreter: /yourpath/to/Xpra.app/Contents/Helpers/Python, or if you cd to the directory that contains it: ./Python.

The .$DISPLAY-fakexinerama file is still missing.

[totaam]

2014-02-06 01:35:40: afarr commented

---

Ok, got the test_window_maximize.py to work.

Behavior is the same as the fullscreen button used for videos in browser.

Also, once it goes fullscreen the fullscreen button is non-responsive and the only way to reclaim that desktop is to SIGINT the python.

The xpra info in the attached text file IS trimmed. I wasn't entirely certain what info might or might not be pertinent, but I eliminated all the window.damage.{stuff}, nearly all the window.batch.{stuff}, the window.client.{stuff}, the window.encoding.{stuff}, and the client.connection.{stuff} .... pretty much everything that didn't seem to pertain to position, focus, property, fullscreen, and size.

I didn't see the few items you listed in comment:5 previously though, and the few elements that I listed in comment:3 seemed like too little information... I will go through the txt file, eliminate everything else, and re-attach it.

I did try to make a point of referring to the monitors in accordance with the results of an xpra info | grep client.screen which I ran before each of the xpra info | grep window sets of data... and I tried to refer to each window in accordance with the grepped window data (with the chrome usually being window[2], the 1440x900 laptop usually being monitor[0] and the 2560x1440 laptop monitor usually being monitor[1]).

I also tried to confirm or correct your work at sorting through the screenshots and corresponding layouts as I tried to present them at the end of each collection of xpra info.

The layout you worked so hard on did help me understand where I'd failed to make things clear. I will dig into the wiki formatting to flesh it out if you'd like... but your layout was so close that I thought some small clarifications would do the trick.

I'll get the rest of it sorted to make it even more clear... and be sure to do likewise with the windows laptop tests that I should be able to run tomorrow... so the confusion of this confused mess will be less painful for each of us.

Ohh, per comment 4 regarding .$DISPLAY-fakexinerama

[jimador@elpatron ~]$ ls -la /usr/lib64/libfake*
lrwxrwxrwx. 1 root root    22 Feb  3 13:02 /usr/lib64/libfakeXinerama.so.1 -> libfakeXinerama.so.1.0
-rwxr-xr-x. 1 root root 11128 Feb  3 13:00 /usr/lib64/libfakeXinerama.so.1.0

/usr/lib64/libfakeroot:
total 156
drwxr-xr-x.  2 root root  4096 Sep  4 10:44 .
dr-xr-xr-x. 98 root root 69632 Feb  3 13:03 ..
lrwxrwxrwx.  1 root root    18 Sep  4 10:44 libfakeroot-0.so -> libfakeroot-tcp.so
-rw-r--r--.  1 root root 40432 Aug 26 09:21 libfakeroot-sysv.so
-rw-r--r--.  1 root root 40480 Aug 26 09:21 libfakeroot-tcp.so

Is this libfakeXinerama.so.1.0 file the one you're looking for? Or is there some other file generated and corresponding to the display the xpra session is attached to which I should be looking for? (None of the xpra info grep permutations I could think of turned up anything either.)

[totaam]

2014-02-06 02:13:34: afarr uploaded file ticket496-osx-laptop_and_external_monitor_tests-2.txt (9.6 KiB)

significantly cropped xpra info output for osx laptop and external monitor tests

[totaam]

2014-02-06 04:34:19: totaam commented

---

Behavior is the same as the fullscreen button used for videos in browser.

Then more than likely, this is a GTK on OSX bug (and hopefully this will not affect win32). And I'm not sure what we can do about it. I will ask gtk-osx.

There was a question about this before: Feature Request: Gtkmacintegration Native Fullscreen? and the answer was: Fullscreen mode is built in to Gtk2 already (using the method call we already use...)

I see another thread with a patch: Mac OSX 10.7+ fullscreen handling - first little patch which talks about ''support for true OSX fullscreen windows to
GTK+''. I'm not sure what "true" means here, and the patch doesn't seem to do much.

The fact that you cannot unfullscreen the test application is because there was no "unfullscreen" button to do so, r5368 adds one.
If the bug occurs on win32, it would be very nice to be able to run this test script... unfortunately, it is very difficult to make wrappers...

I will go through the txt file, eliminate everything else, and re-attach it.

No, please, just present it together with the screenshots, the settings, etc

Having to lookup values in one of the dozens of attachments each time is time consuming and error prone - and also makes it very hard to compare tests, it should be done once.

/usr/lib64/libfakeXinerama.so.1 ...

This confirms that libfakeXinerama is installed correctly.

What I want, for each test configuration is the contents of the file:

~/.${DISPLAY}-fakexinerama

Where ${DISPLAY} is the xpra display number you're using. Probably best to clear all of those fake xinerama files before launch to make sure the one you post is the one that was generated. The values should match the screen settings from xpra info, which should match what the client prints on startup, which should match your screen configuration.

[totaam]

2014-02-06 05:09:57: totaam commented

---

r5369 makes it easier to run the tests on win32: either download the test files to run (must be standalone test files - not all of them are), or set BUNDLE_TESTS=1 in MAKE-INSTALLER.BAT before building (recommended).

Then you can use the newly added Python_execfile.exe by pointing it to test file to run, ie:

cd "Program Files"
cd "Xpra"
Python_execfile.exe tests\xpra\test_apps\test_window_maximize.py

[totaam]

2014-02-06 19:24:42: afarr uploaded file fullscreen-external_monitor-laptop_display_set_above_external_monitor.png (99.1 KiB)

cropped fullscreen on external, laptop display set above

[totaam]

2014-02-06 19:49:15: afarr uploaded file display_layout-laptop_display_set_above_external_monitor-2.png (7.8 KiB)

display layout, laptop set above

[totaam]

2014-02-06 19:52:39: afarr uploaded file laptop_right-laptop_fullscreen-desktop.png (36.4 KiB)

laptop desktop, display set with external on left, fullscreen jumped to external

[totaam]

2014-02-06 19:55:11: afarr uploaded file laptop_right-laptop_fullscreen-desktop-2.png (36.4 KiB)

laptop desktop after fullscreen launch, app jumped to external, external set left of laptop

[totaam]

2014-02-07 00:16:30: maxmylyn commented

---

I went through and tested this on my laptop, which is running Win7 using the r5378 client. As long as I disconnected between moving the screens around, fullscreen would still behave properly on both screens, no matter which setup I had:

• laptop left, external right
• laptop right, external left
• laptop top, external bottom
• laptop bottom, external top

This may be just an OSX issue as I can't reproduce it in Windows.

That being said, I CAN reproduce similar results by rearranging the screens without disconnecting. Also, in a couple of cases, Printscreen wouldn't capture the fullscreen application, only the desktop behind it.

[totaam]

2014-02-07 01:00:06: totaam commented

---

... fullscreen would still behave properly on both screens ...

Good. At last some good news.

That being said, I CAN reproduce similar results by rearranging the screens without disconnecting

It would be worth checking that the .$DISPLAY-fakexinerama file on the server does get updated with the new screen layouts when you rearrange the screens. It probably does.

I believe that the real problem, as noted in comment:5 is that although we use RandR to tell the X11 client applications (the browser in this case) that the screen dimensions have changed (even when they haven't) to try to force them to reload the xinerama configuration, there is no way to force them to do so. Maybe flash doesn't in this case?
To verify, you can install a version of libfakeXinerama compiled with DEBUG=1 and you should see when the library does get called on the terminal that launches the application.

Also, in a couple of cases, Printscreen wouldn't capture the fullscreen application, only the desktop behind it

I don't think we can do much about that. Full screen, OpenGL, override-redirect windows are tricky beasts... Maybe turning OpenGL off would help?

[totaam]

2014-02-07 06:26:37: totaam commented

---

Just thought of a possible (nasty) workaround for OSX, at least until we can come up with a proper fix (wherever/whenever that may be)...

If we can somehow reliably identify the screen that is used for fullscreen gtk applications, we can then tell the server that all the xinerama screens are of that exact size. The fullscreen window will still occasionally appear on the wrong screen if fullscreen is clicked from another screen (nothing we can do about that - it's gtk), but at least the flash player will have the right size and it should look ok.

You can test this by editing the .$DISPLAY-fakexinerama file before launching the browser.

[totaam]

2014-02-10 22:03:46: afarr commented

---

Installing a version of libfakeXinerama compiled with DEBUG=1 and running on an osx laptop with attached external monitor (r5378) I find that

• libfakeXinerama.initFakeXinerama() fires and finds 2 screens on my display when the server is first connected.

• It fires again (twice) when I use an xterm to fire a google-chrome browser.

• It then appears to fire 8 times when I change the display settings.

Editing the .$DISPLAY-fakexinerama file doesn't seem to work though.

• Start by removing it entirely: cat: .:23-fakexinerama: No such file or directory

• Start server session and connect, cat the file:

[jimador@elpatron ~]$ cat \.:23-fakexinerama
# 2 monitors:
2
# monitor 0 (451mm x 282mm)
1440 0 1280 800
# monitor 1 (508mm x 317mm)
0 0 1440 900

• Edit it before starting a browser from an xterm:

[jimador@elpatron ~]$ cat \.:23-fakexinerama
# 2 monitors:
2
# monitor 0 (508mm x 317mm)
1440 0 1440 900
# monitor 1 (508mm x 317mm)
0 0 1440 900

(Note: the smaller monitor is set right in this case, so when using fullscreen there, the fullscreen window will reliably "jump" to the left monitor. I was hoping that editing the file would cause it to then fullscreen to the size of the monitor to which it was expected to jump.)

• The fullscreen window jumps, as expected, to monitor 1, but it displays at the 1280 x 800 size (with the top-menu portion visible, indicating it isn't just positioned in the wrong location, but displaying at the wrong size).

A clipped xpra info | grep window shows (oddly):

window[3].focused=False
window[3].fullscreen=False
window[3].icon-title=Luge - The Canadian Institute of Diversity and Inclusion TV Commercial Ad - YouTube - Google Chrome
window[3].position=(1515, 27)
window[3].property.fullscreen=False

(This was a test run with osx 10.6.8. I'll try it again with 10.9 and post any different results. Let me know if you actually want another screenshot... but it is essentially a re-hash of the right-most NOK of the second row of the previous chart.)

[totaam]

2014-02-12 20:13:15: afarr commented

---

Odd, testing the manual re-sizing of the laptop display size in the fakexinerama file on osx 10.9, the fullscreen still jumps and displays at the size of the actual laptop display screen size (1440 900), but rather than displaying the full screen of the video, it seems to crop an image sized to the manually overwritten size (2560 1440) into the smaller laptop display size "frame".

(I have screenshots if you'd like, but at this point more seem unlikely to be useful.)

[totaam]

2014-02-25 00:39:02: totaam changed owner from afarr to smo

[totaam]

2014-02-25 00:39:02: totaam commented

---

There is a patch for OSX: gnome bug 556007 which should improve things.

Please rebuild gtk-osx with this patch as I am unable to test.

[totaam]

2014-02-27 11:09:17: totaam changed owner from smo to afarr

[totaam]

2014-02-27 11:09:17: totaam commented

---

You can find a beta build using this patch here: [http://xpra.org/beta/]

It may also be useful to compare this build with your own, even for other bugs like #469

[totaam]

2014-03-03 19:35:48: afarr commented

---

The build with the osx patch does indeed fix the fullscreen issue with any arrangement of displays.

It makes me a little giddy to say this ticket should be ready to be closed.

[totaam]

2014-03-04 02:58:16: totaam changed status from new to closed

[totaam]

2014-03-04 02:58:16: totaam changed resolution from ** to fixed

[totaam]

2014-03-04 02:58:16: totaam commented

---

Closing with the caveat that any gtk osx build updates to the gtk module will require re-applying this patch: 0001-quartz-fix-fullscreen-with-dual-monitors.patch