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
_______________________________________________
[email protected]: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: [email protected]
