xf86-video-dummy: resize to exact resolution
Erik Jensen
rkjnsn at google.com
Fri Jun 17 18:14:24 UTC 2016
I originally posted this to xorg, but it was pointed out that this list
would be a better place for it.
TL;DR: I would like to champion getting exact resize support into the dummy
driver, and am wondering what approach would be most likely to get accepted.
When using Xorg with the dummy driver to host a virtual session for remote
access, it is often desirable to resize the session to exactly match the
resolution of the client. While the dummy driver supports switching between
predefined resolutions, it provides no facility for switching to a
resolution not defined in xorg.conf. The common workaround used by tools
such as Xpra seems to be to define a long list of resolution in xorg.conf
and hope the client matches or is close to one of them.
Chrome Remote Desktop is currently exploring support for using Xorg with
the dummy driver instead of Xvfb, but exact resize would be needed for
feature parity. As such, I would like to work to get this functionality
included in the dummy driver. I am looking for feedback regarding the
preferred approach for implementation (see below), and the next steps to
move the process along.
I have found two proposed patches to add this functionality. The first is
https://lists.x.org/archives/xorg-devel/2014-November/044580.html, which
keeps the current virtual monitor model, but updates RandR support to 1.2,
allowing custom modes to be added on the fly using --newmode/--addmode. The
second patch is
https://lists.x.org/archives/xorg-devel/2015-January/045395.html, which
introduces a more fundamental change: it does away with providing a fake
output and fake monitor all together, instead caring only about the virtual
resolution, which can be set using --fb.
The first patch works the same way as the RandR 1.2 support added to Xvfb,
last year, and has the advantage of allowing existing software such as Xpra
to continue to work as is until updated to the new functionality. It has
the disadvantage of requiring one to calculate a mode for the desired
resolution that meets the timing requirements of an imaginary monitor,
create the new mode, add it to the virtual output, and finally switch to
it. Additionally, the maximum resolution that can be specified is limited
by VideoRam, which still can only be specified in the config file.
The second patch has the advantage of making dummy simpler and cleaner: it
is no longer necessary to calculate modelines to work with an imaginary
monitor (and indeed no virtual output is presented), and one only needs to
make a single RandR call to update the virtual size. It also allocates the
needed memory on the fly, so one can pick any size up to 32767x32767. The
main disadvantage is lack of backward compatibility: users would have to
update their xorg.conf to specify "Virtual" instead of mode lines, and
programs expecting to be able to switch between predefined sizes using
RandR 1.0 would stop working. (E.g., Xpra wouldn't be able to resize the
display at all until it was updated.) It is also different from the
approach taken with Xvfb, which means that code wanting to support both
would need to handle them differently. (On the other hand, aside from
Chrome Remote Desktop and Xpra, I'm not sure how many tools are trying to
do something like this.)
A third option would be to take the second approach, but introduce it as a
separate driver, leaving the original dummy for backward compatibility
purposes.
Which approach seems more likely to gain traction?
Thanks,
Erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-devel/attachments/20160617/1dbf86e1/attachment.html>
More information about the xorg-devel
mailing list