# Quoting Preetham ([EMAIL PROTECTED]):

>  I was going thru the docs and found a reference to a regoin.
> 1. What exactly constitutes a region in a framebuffer.
> 2. Does the framebuffer contain the image of the Desktop Screen(Display
> number), is it called Desktop in X, im a ex-windows guy:).
> 3. Is there a way i could get a mirror of the Linux Framebuffer(ie create a
> buff of my own and mirror it with the linux framebuffer)

The following is grossly oversimplified :)

Your graphics card has a chunk of memory which contains the pixel
information for what is on your screen. In the typical case something
like 32 bit for each pixel containing the r/g/b/a values (8 bit each) of
each pixel on the screen. This memory is commonly referred to as the
"framebuffer" since its a buffer for a frame, or screen, or image. 

Now, Windows (TM, whatever, please dont sue me :), or X for that matter,
draws into the framebuffer, which results in the corresponding pixel
values showing up on screen. To do that, and to utilize certain special
features of a certain graphics card (for example acceleration) it needs
a driver (windows) or specific X server which knows how to talk to that
card specifically.

The linux framebuffer device is a kernel level abstraction of the
concept of the framebuffer, which all graphics cards share. What it does
is give userspace a uniform view of above mentioned chunk of memory via
/dev/fb which can be read and written to. This can be looked at as the
smallest common denominator of all graphics devices out there.

You could use it to do all your drawing to screen and not use any card
specific features and indeed, the Xfb server does just that, which makes
it run with pretty much anything that can display pixels. The downside
is, its slow as hell, since all graphics card specific goodies are
bypassed. 

For certain graphics cards, there are accelerated fb drivers (matrox,
aty, some others), which give you the best of both worlds, so to speak.
Those need to be loaded at boot time.

For certain applications, which basically only need to manipulate pixels
directly (such as DirectVNC, a vnc client for the linux framebuffer
device I've written) the overhead of X is unnecessary, so using /dev/fb
makes sense.

As to exporting the contents of your framebuffer via vnc, please refer
to the other thread on the subject. 

Hope that helps,

Till
_______________________________________________
VNC-List mailing list
[EMAIL PROTECTED]
http://www.realvnc.com/mailman/listinfo/vnc-list

Reply via email to