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.
Wish-list: it would also be nice not to have to specify Modelines for
the "dummy monitor" since it should be able to handle things like
3840x2560 as long as enough RAM is allocated to it, right?
I had to add this one to get 2048x2048:
Modeline "2048x2048@10" 49.47 2048 2080 2264 2296 2048 2097 2101 2151
It should, but...
2) If I resize this dummy screen with randr, do I save any memory or cpu
usage during rendering? Are there any benefits at all?
It doesn't seem to have any effect on the process memory usage, I
haven't measured CPU usage yet but I assume there will be at least some
savings there. (the scenario that interests me is just one application
running in the top-left corner - does the unused space matter much?)
I may have dozens of dummy sessions, so savings would add up.
The dummy driver is still using the pre-randr-1.2 model where the
framebuffer is statically allocated up front. It would need a bit of
work to port to the new model. Once you'd done that, though, you'd
pretty much just let it start at whatever resolution it wanted, and then
feed in the desired size with xrandr --addmode at runtime.
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.
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.
* 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.
* 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.
4) Acceleration... Now this last bit really is a lot more far fetched,
maybe I am just daydreaming.
Wouldn't it be possible to use real graphics cards for acceleration, but
without dedicating it to a single Xdummy/Xvfb instance?
What I am thinking is that I may have an under-used graphics card in a
system, or even a spare GPU (secondary card) and it would be nice
somehow to be able to use this processing power from Xdummy instances. I
don't understand GEM/Gallium kernel vs X server demarcation line, so
maybe the card is locked to a single X server and this is never going to
be possible.
Possible, not a near term kind of project yet.
- ajax
_______________________________________________
[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]
