more sensible default vfb resolution on startup

[totaam]

Issue migrated from trac ticket # 1132

component: server | priority: major | resolution: fixed | keywords: x11 resolution xvfb

2016-02-21 11:22:56: antoine created the issue

---

One way to ensure that the Xvfb resolution matches that of the client when the child commands get started is to use the new start-after-connect flag (see #1114#comment:3). But this is not practical in all situations.

Another stop gap measure would be to provide more sensible defaults.
The default initial resolution with xdummy will be the highest resolution available. With the current trunk builds on Fedora (and probably as far back as 0.15.x too), that's:

$ DISPLAY=:100 xdpyinfo | grep dimensions
  dimensions:    8192x4096 pixels (2167x1084 millimeters)

Most clients will be connecting from 1080p or at most 4k.
We should set the screen a resolution that is more likely to be close to the final resolution we set.
According to statistics [http://www.w3schools.com/browsers/browsers_display.asp], I think 1080p is a good bet. (or we could overestimate slightly and go for something like WQHD).
I don't think we want this configurable on the command line either, an env var override should be enough.

This is somewhat related to dpi (#163) and dummy randr (#56).

[totaam]

2016-02-22 05:51:44: antoine changed owner from antoine to afarr

[totaam]

2016-02-22 05:51:44: antoine commented

---

For older versions this kinda works around the issue:

xpra start :100 --start-child=xterm --start="xrandr -s 1920x1080"

But when adding more start commands, there is no guarantee that the xrandr one will have completed by the time the other ones start. (though generally speaking, that's almost always the case since xrandr is very fast to run)

---

Done more "properly" in r12007: we set the xvfb resolution to 1080p on startup.
You can tweak this using:

XPRA_DEFAULT_VFB_RESOLUTION=2560x1600 xpra start ..

Invalid values may cause the server to fail to start, use the value "0" to turn off this feature.
We only set the resolution if it matches one of the default ones exactly.

@afarr: the applications will now see the virtual screen dimensions as being 1080p rather than the huge 8k default we had. This may have an impact on DPI and rendering. We still resize the virtual screen when the client connects (if needed).
Feel free to suggest a better default resolution we can use.

[totaam]

2016-05-20 02:16:12: afarr changed owner from afarr to antoine

[totaam]

2016-05-20 02:16:12: afarr commented

---

Did some testing of this... with XPRA_DEFAULT_VFB_RESOLUTION = 0; 2560x1440; 2560x2490 (the two display desktop size calculated for the system I was testing on); and without specifying the resolution (presumably the 1080p).

I couldn't tell any differences in any behaviors. (For one pass I thought I saw slightly better/crisper rendering with the default vs. the 2560x1440, but it wasn't enough to be convincing on a second pass...).

Since it seems to be performing about the same, I can't think of any reason to use any other default resolution.

One odd note, in one case when trying to use the 2560x2490 resolution the server did seem to hang/fail to start, though it worked every other time I tried that value... it's probably a coincidence, but it happened to fail at the same point (just after the server output line of 2016-05-19 18:19:59,271 GStreamer version 1.6 for Python 2.7) that both of the low-resource servers I was using to test in #1199 were failing. Since it wouldn't fail afterward though, I couldn't get any more logs to compare to see if it might be more of a coincidence.

In any case, this looks like it can be closed, passing it back to you in case there's something I missed in this perhaps too simple & cooperative of tickets.

[totaam]

2016-05-20 02:44:07: antoine changed status from new to closed

[totaam]

2016-05-20 02:44:07: antoine set resolution to fixed

[totaam]

2016-05-20 02:44:07: antoine commented

---

That will do.

[totaam]

2016-09-12 07:26:31: antoine changed status from closed to reopened

[totaam]

2016-09-12 07:26:31: antoine removed resolution (was fixed)

[totaam]

2016-09-12 07:26:31: antoine commented

---

I'm seeing problems with resolutions higher than the default: the windows mapped at locations which were not in the original screen size cannot get pointer events. You first have to move them to a location within the original size then back to where they were.

[totaam]

2016-09-12 11:25:18: antoine commented

---

100% reproducible with:

xpra start --start="xterm -geometry 80x25+3000+500" 

The xterm is mapped when the screen is only set to 1080p... we connect at a higher resolution and re-map it in the same place, which isn't enough apparently.
I believe that this can also occur if we start the child command whilst we requested the initial 1080p resize.
We may have to re-configure some of the windows on startup and whenever the virtual screen size changes.

[totaam]

2016-09-12 13:32:43: antoine changed status from reopened to new

[totaam]

2016-09-12 13:32:43: antoine changed owner from antoine to afarr

[totaam]

2016-09-12 13:32:43: antoine commented

---

Fixed in r13672 + r13673: we clamp the windows to the current desktop size, and apply clamping again when the resolution changes.
This should be race-free too since we listen for screen size changes before we register the list of windows.

@afarr: see comment:5, the xterm was not usable with the mouse before (ie: dragging to select text) when connecting with a 4K monitor, it is usable now.
It won't show up where requested on the xterm command line (3000,500) but clamped to the size of the screen it got mapped on (by default XPRA_DEFAULT_VFB_RESOLUTION=1920x1080).
And this will need to be backported...

[totaam]

2016-09-16 07:33:27: antoine commented

---

Fix in r13753: honour the "resize-display=no" flag and leave it as it is.

[totaam]

2016-09-21 00:27:46: afarr changed status from new to closed

[totaam]

2016-09-21 00:27:46: afarr set resolution to fixed

[totaam]

2016-09-21 00:27:46: afarr commented

---

Tested (building an r13670 1.0 server to compare against) with 1.0 r13786 fedora 23 server against a 1.0 r13673 win32 client.

Saw the issue with the old build, definitely fixed with the new... and --resize-display=no seems to be doing what I presume it should be doing (xterm doesn't seem to be moved nearly as far across my display when using the flag, with the fixed build... landing in what seems to be the same place with the new build as it did, non-interactively, with the older).

All looks well... closing another ticket (which also looks well).

[totaam]

2020-05-20 17:43:22: antoine commented

---

Follow up: #2772