10

The way I understand Linux history, in the early 2000s, Linux introduced the DRI/DRM mechanism and framebuffers, so userland can write to the graphics card directly. Before that, "console" linux was pure text-mode.

How did xfree86 draw itself on screen?

4
  • By, well, drawing on the screen? You may want to detail what you're looking for or what information is missing a bit more, otherwise it's unclear and any answer may have to be way to broad.
    – Raffzahn
    Feb 26, 2020 at 19:32
  • 15
    Actually, @Raffzahn, the question is fine: it's about as clear as it can get for someone who has no idea how X11 can work other than a particular interface he knows about. And you'll note that it's generated a fine answer. It would greatly improve the friendliness of our site if you wouldn't complain about "lack of detail" in every question where the poster doesn't already have deep technical knowledge of what he's posting about, but is looking for leads towards learning that knowledge.
    – cjs
    Feb 27, 2020 at 0:51
  • @cjs Please keep that kind of comments, if you feel the need to make them at all, Meta is the place to go. Comments on the main site are not meant for carrying a personal vendetta. Repeating it is not helpful in any way and degrading in general. I would ask you to keep that down. --- Now, for the question, I didn't see a way to answer in a useful way, so I took the step to ask for a better qualification. Isn't that exactly as it should be? Communicate with the OP to get abetter understanding? Calling an attempt to improve in cooperation seams rather welcoming to me - doesn't it?
    – Raffzahn
    Feb 27, 2020 at 1:08
  • 13
    @Raffzahn I'm simply trying to undo the unwelcoming effect of your poor criticisms of questions from new users. This question, while not perfect, is fine, and is not unclear except to you. If you feel the discussion should be continued in meta, go ahead.
    – cjs
    Feb 27, 2020 at 2:27

2 Answers 2

20

Before we had graphics support in the Linux kernel, any program that wanted to enter graphics mode had to access the graphics card directly. Those programs were generally started with root privileges and asked the kernel to provide direct hardware access from user mode.

Besides the X Server, some tools used SVGAlib, a lightweight library to acces (Super)VGA cards in graphics mode, and there was SVGATextMode, a program to set up high resolution text modes. Also, the mis-named tool dosemu (which is in fact a VM monitor that boots a real DOS) had a mode called "console mode", in which it claimed access to the graphics card and passed those access rights to the 8086 VM, so the native video BIOS of the graphics card could be used by DOS applications to set any mode supported by the card.

As the user application reprogrammed the graphics card without the kernel knowing about it, the user application also was responsible for re-setting the card to a sane text mode and telling the kernel that the graphics card is usable again. If an application crashed in graphics mode, the console was unusable. If the keyboard was not in raw mode (later Linux versions allowed Alt-SysRq-R to leave raw mode), one could try the script textmode bundled with SVGAlib that reprograms the graphics card to a clean text mode, provided the text mode settings were saved with savetextmode before messing up the graphics card state. Another option was to use mode3, which used the video BIOS to reinitialize the graphics card to the standard text 80x25 mode (thanks ninjalj for the pointer).

6
  • 2
    It was called mode3 (nothing to do with mode2, which is for infrared devices).
    – ninjalj
    Feb 26, 2020 at 21:41
  • Besides svgalib, direct vga access could also be used. Looking at the Allegro 4 docs, it supported GFX_SVGALIB, GFX_VGA, GFX_MODEX, GFX_FBCON (Linux framebuffer device), and GFX_VBEAF (with acceleration, there were drivers for Riva TNT cards, and not much else, IIRC).
    – ninjalj
    Feb 26, 2020 at 21:52
  • mode3 and vga_reset used lrmi (Linux Real Mode Interface) to run actual graphics BIOS code, quite like in dosemu. These tools were unrelated to svgalib, and appeared way later than the first svgalib releases. The svgalib tool I thought about is called restoretextmode, and there are wrapper scripts savetextmode (saves a dump of the graphics card state to a file in /etc/vga or ~/.vga) and textmode (restores the graphics card state from that dump). Feb 26, 2020 at 21:59
  • Yes, apparently later svgalib releases bundled a modified version of lrmi, thus my confusion.
    – ninjalj
    Feb 26, 2020 at 22:09
  • 1
    Specifically with mmap on /dev/mem, IIRC. (Later kernels allowed disabling user-space from doing that for at least some parts of /dev/mem) Feb 27, 2020 at 20:57
5

DRM is about commands given to the processor of the graphics hardware. It's a common interface for a variety of different graphic processors.

Before, there was either special X11 drivers which featured some acceleration for common operations, e.g. copying some rectangle from invisible parts of the video memory into the visible parts. Or the main CPU had to do this. Copying from main memory to video memory is always possible as somehow the video memory has to be populated in first place.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .