What is the absolute lowest level of "drawing" abstraction in GNU/Linux?

Question

Motivation - Write a program in C (and Assembly, if required) to color a rectangular area in the screen red.

STRICT requirements - GNU/Linux running with the bare minimum utilities and interfaces in text/console mode. So no X (or equivalent like Wayland/Mir), no non-default (outside POSIX, LSB, etc. provided by the kernel) library or interface and no extra assumptions except the presence of the device driver for the monitor.

Effectively, what I am looking for is information on how to write a program which will eventually send a signal through the VGA port and cable to the monitor to color a particular portion of the screen red.

Apologies if this sounds rude, but no "Why do you want to do this?" or "Why don't you use ABC library?" answer. I am trying to understand how to write an implementation of the X server or a kernel framebuffer (/dev/fb0) library for example. It is ok to provide a link to the source of a C library.

Fabrianna

wiki.osdev.org/VGA_Hardware – Pug

OpenGL is, as the name implies, open. I suppose you may find some hint for what you want to do there. It is very low level, i.e. points, lines, triangles, colors. The source code should help you to see example of how this library works, and there is a great amount of documentation. [Look Here] (#3353148) for source code possibilities. – Reiss

The point is to deal with various very different graphics cards. AFAIK, the common subset is VGA which is obsolete today (too small resolution, etc...). You'll need to dive into hardware specific stuff, and the pain begins there.... Wayland or X provides you a common abstraction to deal with various graphical cards.... – Cowling

a quick search on the net will give you all possible algorithms for drawring lines/rectangle/... to a pixel buffer. And you can use eg FreeType for fonts. Combine with direct framebuffer access (#1527539) and you're up and running. – Hewie

@Pug The link seems to provide the kind of information I am looking for. – Fabrianna

@Hewie Thanks. I was not looking for algorithms right now, but the simplest of mechanisms to draw. Your link contains relevant code. Is it safe to assume that any graphics library including Xlib uses the same method? – Fabrianna

@MozanSykol: That would be incorrect. As ryyker and Basile pointed out, modern graphic cards can do many things natively. This is far more efficient, so graphics libraries try to avoid duplicating that functionality. – Fears

@BasileStarynkevitch: Actually Wayland doesn't deal with drawing things at all. It's mostly a framebuffer management and content passing protocol. With Wayland you use OpenGL(-ES), OpenVG or such for drawing. – Anisometric

Answer 1

no extra assumptions except the presence of the device driver for the monitor.

That means you can use X or Wayland, because those are the graphics driver infrastructure on Linux.

Linux (the Kernel) by itself doesn't contain any graphics primitives. It provides some interfaces to talk to the GPU, allocate memory on it and configure the on-screen framebuffer. But except raw framebuffer memory access the Linux kernel does have no way to perform drawing operations. For that you need some infrastructure in userspace.

Wayland builds on top of DRI2, which in turn talks to the DRM Kernel-API. Then you require GPU dependent state tracker. Mesa has state trackers for a number of GPUs and provides OpenGL and OpenVG frontends.

The NVidia and ATI propiatary, closed source graphics drivers are designed to work with X only. So with those to make use of the GPU you must use X. That's the way it is.

Outside of that you can manipulate the on-screen framebuffer memory through /dev/fbdev, but that's mere pixel pushing, without any GPU acceleration.

Anisometric

So if I process the comments on the question and this answer, this is what I conclude. Theoretically, I can use " some interfaces to talk to the GPU, allocate memory on it and configure the on-screen framebuffer" to create my own display infrastructure or my own OpenGL-like library in a GPU dependent way. I can also use /dev/fbdev without benefits of GPU acceleration. Practically, I would use the graphics driver, but the driver of the major vendors are dependent on X. A quick last question - how does ncurses creates GUI-like interfaces in console mode? – Fabrianna

@MozanSykol: Yes, this is essentially how it works. Well, ncurses uses the ordinary text mode. The console is a N×M grid of characters and attributes (color, background, blink). Good old VGA directly supports this, i.e. by writing the right values at the right place of memory a VGA compliant graphics card will draw the text according to this. Where VGA is not available, the Linux kernel can emulate this through the raw framebuffer memory device (/dev/fbdev). But text mode can't do any kind of fancy graphics. – Anisometric

Answer 2

Once upon a time we we had svgalib (or was it called vgalib?) which did exactly what you are trying to do. I would recomend that you look at its source code. I don't know if it is still possible to find it anywhere, or if it would actually work with a modern kernel. Just whatever you do, be prepared to reboot often.

Camilia

SVGALib looks useful. Wikipedia claims that it can be used as a driver for SDL but Wikipedia is often misleading on programming related stuff. Need to experiment to find out if it works. – Fabrianna

Answer 3

For whatever it's worth, for any future viewers, I have found a decent tutorial at http://betteros.org/tut/graphics1.php. It goes through Framebuffer, DRI/DRM, and X Windows at "the lowest level possible" (basically ioctls and file read/write).

I have gotten both the Framebuffer and DRI/DRM examples to work on both QEMU Debian (on a MacOS Host) and a Raspberry Pi, with a bit of modification for the latter.

Regatta