Testing with both 1.0 r14402 fedora 23 server against a 1.0 r14397 windows client and 0.17.1 r 12453 fedora 23 server against a 0.17.5 r13487 windows client... with two displays, I'm finding that maximizing a browser window (chrome, firefox) causes it to size across both displays... but only if I maximize from the left-most display.
Fullscreen with videos behaves as expected.
I'll attach client-side logs for both combinations with -d window
... looks like there's a init_max_window_size(..) max-window-size changed from (0, 0) to (4096, 4096), because of max viewport dims (8192, 8192) and max backing dims (4096, 4096)
call being made in each case, with a desktop/display set up of:
desktop size is 3840x1080 with 1 screen: Default (1016x285 mm - DPI: 96x96) workarea: 3840x1040 DISPLAY1 1920x1080 at 1920x0 (621x341 mm - DPI: 78x80) workarea: 1920x1040 DISPLAY2 1920x1080 (621x341 mm - DPI: 78x80) workarea: 1920x1040
1.0 client logs with -d window
0.17.x client logs with -d window
Are there any differences between the 1.0 branch and 0.17? Is this a regression? The log sample for 1.0 does have a maxmimize event:
configure event: current size=(930, 517), new size=(4096, 4096), backing=gtk2.GLWindowBacking(2, (930, 517), None), iconified=False
But the 0.17.x does not. It would be good to have working case vs non-working case, using the same xpra version - to make it easier to compare.
It could also be opengl related: have you tried turning it off? (or on?)
Can you try to run the client with XPRA_WIN32_WINDOW_HOOKS=0
to see if that makes any difference?
If it does, then it's going to be one of those flags (unset XPRA_WIN32_WINDOW_HOOKS first): XPRA_WIN32_UNDECORATED_STYLE=0
, or XPRA_WIN32_MAX_SIZE_HINT=0
or XPRA_WIN32_GEOMETRY=0
.
Please include the debug output with these extra debug flags: "geometry", "screen" and "win32".
It could also be opengl related: have you tried turning it off? (or on?)
Turning OpenGL off causes the misbehavior to stop.
Can you try to run the client with XPRA_WIN32_WINDOW_HOOKS=0 to see if that makes any difference?
Yes, it makes a difference. I uhh can't maximize anymore - the option is greyed out. So, technically that fixes it. However, I have a feeling that's not an elegant solution.
Option | Effect? |
XPRA_WIN32_UNDECORATED_STYLE=0 | no |
XPRA_WIN32_MAX_SIZE_HINT=0 | no |
XPRA_WIN32_GEOMETRY=0 | fixed it! |
Looks like the XPRA_WIN32_GEOMETRY=0
option fixed it. Will attach requested logs in a sec (on other machine)
Connected, maximized, unmaximized, disconnected
Connected, maximized, unmaximized, disconnected
Connected, maximized, unmaximized, disconnected - this one worked as expected
Note: I was testing this with a Win8.1 machine with two 1080p monitors attached (one is a 1440p monitor, the other is 4K, but I lowered the resolutions to match), with a r14469 trunk client against a trunk r14470 Fedora 24 server.
My steps were very straight forward:
The XPRA_WIN32_GEOMETRY
controls whether we hook apply_maxsize_hints
or not.
When we hook it, we will ensure windows don't grow bigger than a certain size. This is needed if the application makes that request, or if we do. ie: to ensure we don't overflow the opengl texture / viewport limits, or to keep it within the "workspace" area.
We use our own hook because if we leave to GTK, it hides the maximize button, as you found out.
From your log sample, I see:
apply_maxsize_hints(GLClientWindow(2 : gtk2.GLWindowBacking(2, (1248, 848), None)), \ {'max_width': 4096, 'min_height': 118, 'base_width': 300, 'max_height': 4096, 'min_width': 300, 'base_height': 118}) found max: 4096x4096
Then later on the system uses our hook to constrain the window geometry:
on_getminmaxinfo window=0x140822 max_size=(4096, 4096), frame=8x8, minmaxinfo size=4112x4135
And also:
OpenGL enabled with Intel(R) Iris(TM) Graphics 5100
It's very likely that this chipset is limited to 4kx4k textures (you can verify with the opengl_check.exe tool)
causes it to size across both displays... but only if I maximize from the left-most display
You're not stating what happens if you're on the right-most display.
Does it maximize only on that monitor?
What is the difference between "undecorated" and "maxsizehint" logs?
Do you have logs of "working" (left) and not-working (right) doing the same steps to compare?
I can't reproduce at the moment since virtualbox doesn't do enough opengl to test.
Requested log - connected, moved Firefox to the right monitor, maximized and unmaximized twice, moved it to the left monitor, then maximized and unmaximized twice
If I move Firefox to the right monitor, it'll maximize and unmaximize fine (as in on the correct monitor). Maximizing and unmaximizing on the left monitor causes the browser to maximize across both monitors.
What is the difference between "undecorated" and "maxsizehint" logs?
I used the XPRA_WIN32_UNDECORATED_STYLE=0
flag in the "undecorated" log, and the XPRA_WIN32_MAX_SIZE_HINT=0
flag in the "maxsizehint" log. Same steps for all of them.
Do you have logs of "working" (left) and not-working (right) doing the same steps to compare?
Just attached another log sample. This time, I connected, then moved firefox to the rightmost monitor and maximized and unmaximized a couple times. After a second, I moved it to the left monitor and did the same. On the right monitor it maximized fine, and on the left it maximized across both displays.
Passing back to you.
try to always clamp to the monitor size when maximized
just continue to run the other minmax hooks after our one
continue - but via return value
I thought I could still test a fix for this with virtualbox by artificially constraining the window size using the --max-size
switch, but this is behaving as it should on my XP test vm.
I have attached 4 possible fixes which you can try ("window_hooks.*py") To try them, either make a new win32 build from source after replacing the trunk version of the file with one of the files attached, or:
Rinse and repeat for each potential fix.
If that does not help, please include the "-d all" of just the maximize event for both successful and unsuccessful cases.
preserve existing size restrictions if any
This one will have to wait a bit as Smo can't get me builds at the moment, and 7Zip isn't playing nicely and won't let me add files to the archive. (lets me delete no problem)
FYI: on my systems I can just double-click on the library.zip to open it up in windows explorer, then I can just drag and drop files inside the archive. Alternatively, you could use the command line: unzip, modify, zip it again.
Found a workaround - copying the file to another folder under my User directory, I can edit it no problems. (ugh Windows and permissions, blegh)
Dropping in the replacement .py file causes the client to no longer connect. I think it doesn't like that I'm replacing a .pyc with a .py file.
Not sure what to do here. Either way, still no builds from Smo - will ping him.
I think it doesn't like that I'm replacing a .pyc with a .py file.
Do not rename the file. Just copy it as ".py" to the target directory after removing the corresponding ".pyc". Without editing or renaming.
That's what I did and it still complains about not being able to import the library.
Okay, thanks to Smo's hard work, I managed to get 4 different libraries to test. The client is a 1.0 r14492 Win8.1 and the server is at Fedora 24 1.0 r14576.
Here, I'll make a handy table. On the left, I'll note which library file I'm using (each corresponds to the window_hooks) attached to this ticket, and on the right I'll mark if it works and fixes the issue or not.
Which library? | Works? |
1 | works |
2 | doesn't work |
3 | doesn't work |
4 | works |
Looks like the first and fourth window_hoooks.py
are the ones that fix it. Passing back to you. Let me know if you want any more logs.
@maxmylyn: thanks!
Applied version 4 of the patch to trunk in r14581, r14582 for v1.0.x
That did it! Closing.
(tested with the r14619 Win client)
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1354