On 06/14/2016 03:53 PM, Erik Jensen wrote: > 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 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.) > > Which approach seems more likely to gain traction?
Without a champion for either one, neither. :) I'd obviously prefer to make -dummy simpler by removing the fake outputs, but I don't have time at the moment to push for review or look into the crash reported in https://lists.x.org/archives/xorg-devel/2015-September/047331.html -- Aaron _______________________________________________ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
