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)
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:
libfakeXinerama
, at least for the RPM distros
LD_LIBRARY_PATH
for lookup
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
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
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
--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).
--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?)
the display of fullscreen chrome on larger monitor (start-child chrome)
the display of fullscreen on large monitor (start-child firefox)
the (lack of) display of fullscreen on smaller (laptop) monitor (start-child firefox or chrome)
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:
ls -la /usr/lib/libfake*
#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:
.$DISPLAY-fakexinerama
file and not the .fakexinerama
fallback
xpra info
data as per comment:3
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:
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)
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)
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.
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.
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:
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.
Exit server and client session. Set Displays with laptop display above external monitor. Restart.
the layout for first two tests of comment 6 - laptop display left of external monitor
first test of comment 6 - fullscreen on laptop display _ laptop display set left of external
test 2 of comment 6 - fullscreen on external _ laptop display set left of external
layout display second round of tests, comment 6 - external monitor set left of laptop display
first of second round of tests, comment 6 - fullscreen of laptop display _ external display set left of laptop (nothing displayed on laptop screen)
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
secvond test of second round, comment 6 - fullscreen on external monitor displays as expected (for completeness) _ external monitor set left of laptop display
first test of third round, comment 6 - fullscreen on laptop display _ laptop display set above external monitor
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:
.$DISPLAY-fakexinerama
file
xpra info
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?
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 |
---|---|---|---|
![]() | OK / NOK | ![]() ![]() | ![]() ![]() |
![]() | OK / NOK | ![]() ![]() | ![]() ![]() |
![]() | NOK / OK | ![]() ![]() | ![]() ![]() |
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
|
same as before, but chopped and resized
same as before, but chopped and resized
same as before, but chopped and resized
same as before, but chopped and resized
same as before, but chopped and resized
same as before, but chopped and resized
placeholder for missing screenshot of laptop screen
placeholder for missing screenshot of external screen
re-sized screenshot, fullscreen on laptop display, displays on wrong monitor
fullscreen on laptop display, when set above external monitor, displays askew
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.)
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.
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.)
significantly cropped xpra info output for osx laptop and external monitor tests
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.
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
cropped fullscreen on external, laptop display set above
display layout, laptop set above
laptop desktop, display set with external on left, fullscreen jumped to external
laptop desktop after fullscreen launch, app jumped to external, external set left of laptop
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.
... 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?
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.
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.
Editing the .$DISPLAY-fakexinerama
file doesn't seem to work though.
cat: .:23-fakexinerama: No such file or directory
[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
[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.)
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.)
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.)
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.
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
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.
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
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/496