The Framebuffer API, and drivers generally

I've seen incomplete (not yet started) docs on JNode's framebuffer API. In the current source code package I can't find anything that mentions parts of the API like the "surface" for example.

Does anyone know how framebuffer graphics cards operate? After we have identified the card with its PCI ID (for PCI, PCI-X and AGP cards?) the registers and I/O space or whatever (presumably this is fetched from PCI config space, but I don't know...) then what is the general procedure for writing a framebuffer driver for that card?

Is a framebuffer just a memory-mapped area that when you write data in there, it appears on the screen? What format is the data? Do you need to know about colour spaces, like RGB and YUV and so on (4cc)? Big endian, little endian? Bits per pixel, configuring the card? As far as we can abstract the common features of every framebuffer device, what are the general principles?

Lastly, does anyone know how graphics card acceleration works? Is there a general way most cards do this, simply by writing commands to registers or I/O space or something, and somehow getting the card to accelerate 3D? (How would it accelerate 3D anyway? Does it just do 3D mathematical computations or does it take a bunch of frames and refresh the screen so many fps or something?)

Thanks for your help. It would be very good to have good hardware documentation like this for graphics/video cards, sound cards, network cards, disk drives, I/O extension cards, etc. so that programmers who may have written a driver before and knows the basics like kernel vs. user mode and whatever can be wooed across to write drivers needed in other areas.

I would write all the docs if someone has the time to answer my questions. I would also write drivers, demo drivers/examples and test and debug; possibly other things as well.

JNode could be very educational by being the first OS to have decent documentation on how the hardware works so programmers can write drivers. Smiling (I mean, so programmers who are not the very best in the world can write a decent, stable device driver.)

Cheers,
James

Answers .. I hope

Hi James,

I hope to answer most of your questions, since I wrote most of the graphics drivers.

Most graphics cards today have a large block of memory that is mapped in the address space of the CPU. The memory is used to store the framebuffer, but also all kinds of bitmaps, and other graphics objects. The graphics card then has high speed access to this memory.

The problem with graphics cards today is that they are all different. Fortunately we have PCI which at least gives us a positive identification of the hardware, but how to control the hardware is very much different for each card, although within cards of the same manufacturer, there are usually architectures that are similar in how they are used.

There are still some issues that are pretty much common.
The format of the framebuffer has more or less standardized on 32bpp (although cards support many other formats). Almost all cards have a set of registers that are used to control the hardware (the number, location and meaning of the registers is totally different). And there are similar terminologies. Topics like PLL's, vertical sync, horizontal sync etc are similar / equal in concept; not in how they are used / implemented.

Things get even worse when you talk about hardware acceleration (eith 2D or 3D). Then concepts are again similar, but the way to control it is very much different. A problem here is that finding good specifications about this is pretty hard. ATI has a developer program where you can get specs if you sign an NDA, but NVidia does not give specs to anyone.

Now about JNode. You can find all the graphics stuff in the JNode-GUI subproject. We've tried to make as much shared code as possible, but (as you can understand from my story above), the actual drivers are still pretty different.

I hope this helps. Feel free to ask more, or join us on our IRC channel.

Ewout