# 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