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

Motivation - Write a program in C (and Build if necessary) to color a rectangular area on a red screen.

STRICT Requirements - GNU / Linux works with minimal utilities and interfaces in text / console mode. Thus, there is no X (or equivalent, such as Wayland / Mir), no library (non-standard) (outside of POSIX, LSB, etc., provided by the kernel), and also no additional assumptions other than the presence of a device driver for the monitor.

In fact, I'm looking for information on how to write a program that will ultimately send a signal through a VGA port and cable to a monitor in order to color a certain part of the screen in red.

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

+6
source share
3 answers

There are no additional assumptions except the presence of a device driver for the monitor.

This means that you can use X or Wayland because it is the graphics driver infrastructure in Linux.

Linux (the kernel) itself does not contain graphical primitives. It provides some interfaces for communicating with the GPU, allocating memory on it, and setting up the on-screen framebuffer. But, with the exception of access to the raw memory of the framebuffer, the Linux kernel does not have the ability to perform drawing operations. To do this, you need infrastructure in user space.

Wayland is based on DRI2, which in turn is negotiating with the DRM API. Then you need to monitor the status of the GPU. Mesa has state trackers for a number of GPUs and provides OpenGL and OpenVG interfaces.

NVidia and ATI players with closed source graphics drivers are designed to work only with X. Therefore, in order to use the GPU, you must use X. It is as it is.

In addition, you can manipulate the framebuffer's screen memory with /dev/fbdev , but this is a simple click on a pixel without GPU acceleration.

+1
source

We once had svgalib (or was it called vgalib?), Which did exactly what you are trying to do. I would recommend you look at its source code. I donโ€™t know if it can still be found anywhere, or if it really works with a modern kernel. Just, whatever you do, be prepared to reboot frequently.

+1
source

For all future viewers, I found a decent tutorial at http://betteros.org/tut/graphics1.php . It passes through Framebuffer, DRI / DRM and X Windows at the โ€œlowest possible levelโ€ (mainly ioctls and read / write files).

I got Framebuffer and DRI / DRM examples for working both on QEMU Debian (on the MacOS host) and on the Raspberry Pi with a slight modification for the latter.

0
source

Source: https://habr.com/ru/post/952661/


All Articles