How the actual graphics library works?

[luxianos]

Hi, I have been reading for weeks and i've readed a lot of code but I have many doubts yet. In graphics libraries like Cairo, Allegro, or in the Xorg, the Windows GUI, Linux GUI, or Android; how implements the contact with the hardware?
In primitive code we can access to the video memory and start writing there, but in moderns systems applies the same method? What about the graphics cards? I think these are not mapped in memory ¿its true?

I readed the code of Cairo, Allegro, and the code of Android from https://github.com/android but I don't found the low level contact with the hardware.
Thanks a lot!!

[bluemoon]

The GUI is not bound to hardware, you don't want to have infinite versions of GUI framework with all the video cards.
The hardware specific things is handled by the driver, and each OS has a defined driver interface.

[TylerH]

I think OP is asking how the drivers do what they do.

Unfortunately, AFAIK, the answer to that is pretty much unavailable to us for most current video cards. See here for a lot of what has been disclosed: http://wiki.osdev.org/Accelerated_Graphic_Cards.
And here for drawing without interfacing with video cards: http://wiki.osdev.org/Drawing_In_Protected_Mode.

[gerryg400]

I readed the code of Cairo, Allegro, and the code of Android from https://github.com/android but I don't found the low level contact with the hardware.
Thanks a lot!!

I've just started porting Cairo and Freetype to my primitive VBE based graphics driver. Unfortunately it's not simple because the libraries you mention need a 'backend' between the library and the driver. There are numerous backends, X, openGL, glitz, pdf and also a frame-buffer backend but they are of no use to us.

The frame-buffer sounds promising but the bad news is that the 'frame-buffer' is a Linux kernel driver. Not a simple frame buffer in memory. I'm still weighing up my options but will probably end up modifying the frame buffer backend to be more generic and fit it to my driver.