<div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I have found two proposed patches to add this functionality. The first is <a href="https://lists.x.org/archives/xorg-devel/2014-November/044580.html">https://lists.x.org/archives/xorg-devel/2014-November/044580.html</a>, 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 <a href="https://lists.x.org/archives/xorg-devel/2015-January/045395.html">https://lists.x.org/archives/xorg-devel/2015-January/045395.html</a>, 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.</div><div><br></div><div>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.</div><div><br></div><div>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 that 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.)</div><div><br></div><div>Which approach seems more likely to gain traction?</div><div><br></div><div>Thanks,</div><div>Erik</div></div>