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

Antoine Martin antoine at nagafix.co.uk
Wed Apr 6 14:37:52 PDT 2011


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



More information about the xorg mailing list