[SDL] again with doubts on Xlib

[Tom Barnes-Lawrence]

On Wed, 23 May 2007 12:54:02 +0530
"Pavan Krishnamurthy" <2pavan at gmail.com> wrote:


> My first doubt: Is Xserver running in user space? if so can it map the video
> memory in it address space? If not, how does it copy the video data to video
> memory?

Xservers normally are user-mode programs (IE, not kernel processes), but run
as Root, meaning they have essentially as much hardware access as they like,
just like the kernel does. It may sound strange or wrong, but it's relatively
practical it seems.


> which driver is used by the Xserver to access the video memory?

AFAIR, the servers normally just access it directly like any other memory, but
have their own internal "drivers" to deal with different cards having different
control registers and features and video memory layouts and whatever else. I
don't know much about this side of things though, so if someone else says
otherwise they probably know better than me! :D

There are also framebuffer-based X-servers that go through the kernel's /dev/fb
drivers, but these AFAIK do not give any acceleration, and most X-servers don't
use the kernel framebuffer drivers at all(?).


>In normal X application, the video data is copied twice:
>   1. From application to Xserver memory.
>    2. Xserver to video memory. Am I correct here?

 That sounds correct from my memory of Xlib programming (I never did too much
of that though, and I much prefer SDL for most things now- although it's not
able to give access to X's line-drawing functions etc). There's also the
MIT-XSHM or whichever extension, but I see you've already heard of that. That
IIRC cuts out step 1 above, but not step 2.  And as you mention next, there
is also DGA which cuts out both steps AFAIK.


> Also there is a X extension called DGA ( another one DRI) which claims it
> gives direct access to video memory for the X applications. In what way is
> it different to Directfb?

You would use DirectFB with programs running at the console. You *must not*
use it under X, because DirectFB's access to the video card would clash with
the X-server's. I'm not sure if it's even possible to, maybe one would stop
the other from running, but otherwise you could expect crashes or at least
screen corruption. The DGA and DRI extensions OTOH should not cause problems
with the X-server (assuming you don't write something so buggy that it causes
a crash; I have encountered SDL programs that have locked my machine solid
when they crashed, so I presume that's possible). And of course you can't
use DGA outside of X.

 At least, that is my *understanding* of DirectFB; there could be some
cleverness it carries out that somehow makes things all work fine, but I
would presume otherwise that it would clash with X. Probably even the
DirectFB X-server would clash with other DirectFB programs.


> In the SHM enabled X server, the applications data doesnt go through the
> network layer, instead the data is shared between the application and the
> Xserver through shared memory. Is it possible to get direct access to video
> memory here. Can the video memory be shared to application in this setup?

 AFAIK the SHM part only gives access to the X-server's buffers, and you would
need DGA to access video memory directly. Or just use SDL. What would be wrong
with that? SDL can be set up to use X11 with or without DGA, *and* DirectFB-
I have run some of my programs from the console, although it needed an
environment variable to be set in order to choose which one. It may have
needed another to select the mouse, I don't remember.

 Actually I guess I may have misunderstood: are you porting this library
*from* embedded Linux, or *to* embedded Linux? What is the other platform
in the port?

 BTW: To use shared memory buffers on X-servers with the feature, your program
must use the special X-SHM extension functions, it doesn't just happen
automatically with normal X-lib code! Unless they've changed something in the
past few years. Yet another reason why SDL makes things so much easier... Sam
et al get to worry about all this awful stuff, and we can just concentrate on
the higher-level code for our own projects.

Hope this helped a bit, sorry I'm no expert. If I got anything wrong, please
feel free to correct me, anyone.
-Tom Barnes-Lawrence
-- 
I think I need a new signature