Has anyone implemented a colour framebuffer console for their OS? I've been studying the Linux framebuffer sources, but it's not obvious to me how the fonts work. Normally there's a couple of standard VGA/SVGA fonts, 8x8, 16x8, or whatever they are. Where do these fonts come from, how are they loaded and used?
Does anyone have details on an implementation of graphics using VESA BIOS Extensions r3? Do they work well? What are the limitations of this, before you hit the wall and need the AF spec and/or card-specific register details?
Is this the way a GUI could be implemented at the lowest level (Tim?) Would the framebuffer memory for rendering be mapped to some virtual address accessible by the graphics driver, which would repaint/update the screen? VESA specifies "windows" in their spec, is this a kind of portal in the framebuffer that a GUI implementation can use to support widgets like frames, menus, a desktop background and all this kind of stuff?
Too bad I can't find a textbook on video programming that's recent and covers SVGA, leaving pre-VGA stuff for dead...
Video framebuffer
-
Tim
Re:Video framebuffer
I've got a graphical console working. I started by targetting 8-bit VGA, then 4-bit VGA. The code for drawing stuff in 4-bit modes lives in the kernel, and is accessed via the video driver, whereas all the drawing for 8-bit modes happens directly onto the video card's frame buffer.
Fonts are pretty easy. Several places have VGA fonts (e.g. http://www.svgalib.org/ has some, and Mobius has some standard VGA fonts). Each character of a VGA fonts is 8 pixels wide, and there are 256 of them. They tend to be between 8 and 16 pixels high. They're monochrome, so the 8 horizontal bits are packed into one byte. To draw a character, you start at (font + character * char_height), then draw monochrome scan lines by looking at which bits are set in each line.
VESA is pretty cool. I've avoided the issue of non-linear frame buffers by ignoring them, so I target VESA 2. The VESA video driver has a V86-mode thread permamently running, which most of the time is sitting waiting on a Mobius kernel event handle (I've given V86 threads access to all the normal system calls). Then it accepts command to initialise VBE, get a list of modes, and switch modes. I haven't used any of VESA's other features, though I think "window" here refers to a window like at A0000 -- that is, a window onto video memory that's smaller than the total but which can be moved around.
Fonts are pretty easy. Several places have VGA fonts (e.g. http://www.svgalib.org/ has some, and Mobius has some standard VGA fonts). Each character of a VGA fonts is 8 pixels wide, and there are 256 of them. They tend to be between 8 and 16 pixels high. They're monochrome, so the 8 horizontal bits are packed into one byte. To draw a character, you start at (font + character * char_height), then draw monochrome scan lines by looking at which bits are set in each line.
VESA is pretty cool. I've avoided the issue of non-linear frame buffers by ignoring them, so I target VESA 2. The VESA video driver has a V86-mode thread permamently running, which most of the time is sitting waiting on a Mobius kernel event handle (I've given V86 threads access to all the normal system calls). Then it accepts command to initialise VBE, get a list of modes, and switch modes. I haven't used any of VESA's other features, though I think "window" here refers to a window like at A0000 -- that is, a window onto video memory that's smaller than the total but which can be moved around.
-
BI lazy
Re:Video framebuffer
In BlueIllusion, VESA 2.0 is used too, for I didn't want to bother with nonlinear framebuffers. I'm happy to allocate a linear framebuffer and draw to it.
Windows are drawn by the gui service. A graphical Text console registers with the gui service and tells it a PIPE to connect to for fetching data to print it on the screen.
I'm using a vm86 process to issue bios ints, f. ex. for video mode switching. they are easy to use and save quite an amount of work. Sole drawback: I can't get it to run on my toshiba laptop. Damn.
Stay safe
Windows are drawn by the gui service. A graphical Text console registers with the gui service and tells it a PIPE to connect to for fetching data to print it on the screen.
I'm using a vm86 process to issue bios ints, f. ex. for video mode switching. they are easy to use and save quite an amount of work. Sole drawback: I can't get it to run on my toshiba laptop. Damn.
Stay safe