dummy driver and maximum resolutions, config hacks via LD_PRELOAD, etc

[Antoine Martin]

On 04/06/2011 09:13 PM, Adam Jackson wrote:
> On 4/6/11 6:51 AM, Antoine Martin wrote:
> 
>> 1) I can't seem to make it use resolutions higher than 2048x2048 which
>> is a major showstopper for me:
>> Virtual height (2560) is too large for the hardware (max 2048)
>> Virtual width (3840) is too large for the hardware (max 2048)
>>
>> Seems bogus to me, I've tried giving it more ram, giving it a very wide
>> range of vsync and hsync, added modelines for these large modes, etc
>> No go.
> 
> It is bogus, the driver has an arbitrary limit.  Look for the call to
> xf86ValidateModelines in the source, and compare that to (for example)
> what the vesa driver does.
Here's a patch which constifies the hard-coded limits and increases them
to more usable values (4096x4096). I've tested it on Fedora 14 and it
allows me to allocate much bigger virtual screens.

diff --git a/src/dummy_driver.c b/src/dummy_driver.c
index 804e41e..05450d5 100644
--- a/src/dummy_driver.c
+++ b/src/dummy_driver.c
@@ -85,6 +85,9 @@ static Bool   dummyDriverFunc(ScrnInfoPtr pScrn,
xorgDriverFuncOp op,
 #define DUMMY_MINOR_VERSION PACKAGE_VERSION_MINOR
 #define DUMMY_PATCHLEVEL PACKAGE_VERSION_PATCHLEVEL

+#define DUMMY_MAX_WIDTH=4096
+#define DUMMY_MAX_HEIGHT=4096
+
 /*
  * This is intentionally screen-independent.  It indicates the binding
  * choice made in the first PreInit.
@@ -402,8 +405,8 @@ DUMMYPreInit(ScrnInfoPtr pScrn, int flags)
        int apertureSize = (pScrn->videoRam * 1024);
        i = xf86ValidateModes(pScrn, pScrn->monitor->Modes,
                              pScrn->display->modes, clockRanges,
-                             NULL, 256, 2048,(8 * pScrn->bitsPerPixel),
-                             128, 2048, pScrn->display->virtualX,
+                             NULL, 256, DUMMY_MAX_WIDTH,(8 *
pScrn->bitsPerPixel),
+                             128, DUMMY_MAX_HEIGHT,
pScrn->display->virtualX,
                              pScrn->display->virtualY, apertureSize,
                              LOOKUP_BEST_REFRESH);




(snip)
> You'd probably find that the difference in CPU usage was marginal at
> best, you'd only win with smaller framebuffers to the extent that things
> fit in cache better.  But the "unused" space does matter.  We do an
> initial paint of black on the root window, which means all the pages are
> going to be real and not just implied maps of /dev/zero.
Thanks, that's very informative.


>> 3) Are there any ways of doing what the LD_PRELOAD hacks from Xdummy*
>> do, but in a cleaner way? That is:
>> * avoid vt switching completely
> 
> -novtswitch and possibly also -sharevts.  That bit of the problem is a
> bit icky though, it really needs someone to think through the design more.
Do you have any pointers to the icky bits?

>> * avoid input device probing (/dev/input/*)
> 
> I think, though I am not sure, that the trick I put in place forever ago
> of explicitly loading the 'void' input driver will turn that off.
It does work perfectly. Thanks!

>> * load config files from user defined locations (not /etc/X11)
>> * write log file to user define location (not /var/log)
> 
> man xorg.conf, look for the bits about -config and -logfile.
What I meant was that when running as a non-root user (which is one of
the main advantages of using dummy), there are no user paths searched.
(all are in /etc or /usr and it also does not allow relative paths)
Those restrictions make sense for the Xorg suid binary, much less so for
dummy running as a normal user.

I can see how this one would be harder to solve as it is, but how hard
would it be to create a new non-suid "Xdummy" binary which extends Xorg:
* adds -userconfig and -userlog command line options
* removes the ability to load drivers apart from dummy and void
And maybe also trim the options which are not relevant to dummy.

(snip)

Thanks
Antoine