Xpra: Ticket #496: support multi-head configurations better - fix fullscreen?

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



Fri, 31 Jan 2014 10:41:16 GMT - Antoine Martin: status, milestone changed

Seems to be working for me with r5323. Note: this requires installing libfakeXinerama.so.1 (modified source which we now keep here: 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:

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

Fri, 31 Jan 2014 21:49:45 GMT - Smo:

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

Fri, 31 Jan 2014 22:06:26 GMT - alas:

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

(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?)


Fri, 31 Jan 2014 22:07:50 GMT - alas: attachment set

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


Fri, 31 Jan 2014 22:08:32 GMT - alas: attachment set

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


Fri, 31 Jan 2014 22:10:05 GMT - alas: attachment set

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


Sat, 01 Feb 2014 00:42:52 GMT - Antoine Martin:

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:


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:


Sat, 01 Feb 2014 06:53:57 GMT - Antoine Martin:

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:

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.


Sat, 01 Feb 2014 07:51:45 GMT - Antoine Martin: owner, status changed

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

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


Tue, 04 Feb 2014 23:22:09 GMT - alas:

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:

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

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


Tue, 04 Feb 2014 23:23:40 GMT - alas: attachment set

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


Tue, 04 Feb 2014 23:25:44 GMT - alas: attachment set

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


Tue, 04 Feb 2014 23:27:18 GMT - alas: attachment set

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


Tue, 04 Feb 2014 23:28:19 GMT - alas: attachment set

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


Tue, 04 Feb 2014 23:30:22 GMT - alas: attachment set

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


Tue, 04 Feb 2014 23:32:31 GMT - alas: attachment set

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


Tue, 04 Feb 2014 23:34:06 GMT - alas: attachment set

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


Tue, 04 Feb 2014 23:36:19 GMT - alas: attachment set

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


Wed, 05 Feb 2014 04:00:37 GMT - Antoine Martin:

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..


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

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?


Wed, 05 Feb 2014 04:17:34 GMT - Antoine Martin:

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 ResultsFullscreen attempt on first ScreenFullscreen attempt on second Screen
same as before, but chopped and resized OK / NOK same as before, but chopped and resized placeholder for missing screenshot of external screenplaceholder for missing screenshot of laptop screen
same as before, but chopped and resized OK / NOK same as before, but chopped and resizedplaceholder for missing screenshot of laptop screen re-sized screenshot, fullscreen on laptop display, displays on wrong monitorlaptop desktop after fullscreen launch, app jumped to external, external set left of laptop
display layout, laptop set aboveNOK / OKfullscreen on laptop display, when set above external monitor, displays askewplaceholder for missing screenshot of external screenplaceholder for missing screenshot of laptop screencropped fullscreen on external, laptop display set above


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


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).


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



Wed, 05 Feb 2014 04:18:26 GMT - Antoine Martin: attachment set

same as before, but chopped and resized


Wed, 05 Feb 2014 04:18:53 GMT - Antoine Martin: attachment set

same as before, but chopped and resized


Wed, 05 Feb 2014 04:19:12 GMT - Antoine Martin: attachment set

same as before, but chopped and resized


Wed, 05 Feb 2014 04:19:28 GMT - Antoine Martin: attachment set

same as before, but chopped and resized


Wed, 05 Feb 2014 04:19:44 GMT - Antoine Martin: attachment set

same as before, but chopped and resized


Wed, 05 Feb 2014 04:20:32 GMT - Antoine Martin: attachment set


Wed, 05 Feb 2014 04:20:47 GMT - Antoine Martin: attachment set

same as before, but chopped and resized


Wed, 05 Feb 2014 04:37:17 GMT - Antoine Martin: attachment set

placeholder for missing screenshot of laptop screen


Wed, 05 Feb 2014 04:37:33 GMT - Antoine Martin: attachment set

placeholder for missing screenshot of external screen


Wed, 05 Feb 2014 22:56:51 GMT - alas: attachment set

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


Wed, 05 Feb 2014 23:25:11 GMT - alas: attachment set

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


Wed, 05 Feb 2014 23:59:09 GMT - alas:

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.)


Thu, 06 Feb 2014 00:38:31 GMT - Antoine Martin:

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.


Thu, 06 Feb 2014 01:35:40 GMT - alas:

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.)


Thu, 06 Feb 2014 02:13:33 GMT - alas: attachment set

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


Thu, 06 Feb 2014 04:34:19 GMT - Antoine Martin:

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.


Thu, 06 Feb 2014 05:09:56 GMT - Antoine Martin:

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

Thu, 06 Feb 2014 19:24:42 GMT - alas: attachment set

cropped fullscreen on external, laptop display set above


Thu, 06 Feb 2014 19:49:15 GMT - alas: attachment set

display layout, laptop set above


Thu, 06 Feb 2014 19:52:38 GMT - alas: attachment set

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


Thu, 06 Feb 2014 19:55:11 GMT - alas: attachment set

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


Fri, 07 Feb 2014 00:16:30 GMT - J. Max Mena:

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:

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.


Fri, 07 Feb 2014 01:00:05 GMT - Antoine Martin:

... 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?


Fri, 07 Feb 2014 06:26:36 GMT - Antoine Martin:

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.


Mon, 10 Feb 2014 22:03:45 GMT - alas:

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

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

(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.)

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.)


Wed, 12 Feb 2014 20:13:14 GMT - alas:

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.)


Tue, 25 Feb 2014 00:39:01 GMT - Antoine Martin: owner changed

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.


Thu, 27 Feb 2014 11:09:16 GMT - Antoine Martin: owner changed

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


Mon, 03 Mar 2014 19:35:48 GMT - alas:

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.


Tue, 04 Mar 2014 02:58:16 GMT - Antoine Martin: status changed; resolution set

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


Sat, 23 Jan 2021 04:57:22 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/496