Now that we understand the basic ideas behind video card technology and mode setting, we can now look at how the framebuffer devices abstract them. Also, we will see that fbdev actually handles most of the mode setting issues for you to make life much easier. In the older API, the console code was heavily linked to the framebuffer devices. The newer API has now moved nearly all console handling code into fbcon itself. This allows for massive code reduction and easier driver development. A good example of a framebuffer driver is the virtual framebuffer vfb.
|Published (Last):||8 February 2011|
|PDF File Size:||8.61 Mb|
|ePub File Size:||8.26 Mb|
|Price:||Free* [*Free Regsitration Required]|
Now that we understand the basic ideas behind video card technology and mode setting, we can now look at how the framebuffer devices abstract them. Also, we will see that fbdev actually handles most of the mode setting issues for you to make life much easier. In the older API, the console code was heavily linked to the framebuffer devices.
The newer API has now moved nearly all console handling code into fbcon itself. This allows for massive code reduction and easier driver development.
A good example of a framebuffer driver is the virtual framebuffer vfb. The vfb driver is not a true framebuffer driver. All it does is map a chunk of memory to userspace. It's used for demonstration purposes and testing. The framebuffer drivers depend heavily on four data structures. These structures are declared in fb.
The first three can be made available to and from userland. First let me describe what each means and how they are used. This defines the properties of a card that are created when you set a mode and can't be changed otherwise. A good example is the start of the framebuffer memory.
This can depend on what mode is set. Now while using that mode, you don't want to have the memory position change on you. In this case, the video hardware tells you the memory location and you have no say about it.
This allowed for forbidden things such as setting a mode of x on a fix frequency monitor. This defines the current state of the video card.
Here I describe a clean way to code your drivers. A good example of the basic layout is vfb. In the example driver, we first present our data structures in the beginning of the file. This can be done since monitors are independent in behavior from video cards. First, we define our three basic data structures. For all the data structures I defined them static and declare the default values. The reason I do this is because it's less memory intensive than to allocate a piece of memory and filling in the default values.
There are two functions that handle the video card at boot time:. In the example driver as with most drivers, these functions are placed at the end of the driver.
Both are very card specific. In order to link your driver directly into the kernel, both of these functions must add the above definition with extern in front to fbmem. Add these functions to the following in fbmem. Setup is used to pass card specific options from the boot prompt of your favorite boot loader. A good example is:. This function has to consider bus and platform handling since today most cards can exist on many platforms.
Also, some platforms offer firmware that returns information about the video card. In this case, we often don't need to deal with the bus unless we need more control over the card. If you are going to use Open Firmware to initialize your card, you need to add the following to offb. If Open Firmware doesn't detect your card, Open Firmware sets up a generic video mode for you. Now in your driver you really need two initialization functions. In fact, that's the use of the user flag. If user equals zero then fbcon wants to access this device, else it's an explicit open of the framebuffer device.
This way, you can handle the framebuffer device for the console in a special way for a particular video card. These are the functions that are at the heart of mode setting. There do exist a few cards that don't support mode changing. It can check them as well. You MUST check the mode before all things. Note that this function is very card specific, but I will attempt to give you the most general layout.
To use this properly, you must understand colors, which is described above. This routine sets a color map entry. For pseudocolor modes, this color map index regno represents the pixel value. In this case, we simulate a pseudo color map. The reason for this is the console system always has a color map, which has 16 entries.
The first 16 is for the console colors and the last one for the cursor. This is, of course, taken care of by fbcon. You just need to code the "formula" that does this translation. An example follows for bit mode:. Here, we first scale down the color components. For bit mode, each color is 8 bits in size. Next, we OR the colors together after we have offseted them. Regno is the index to get this particular color. That does it for required functions besides the set of needed accel functions, which has not been discussed yet.
This function provides support for hardware blanking. This is a great power saving feature on a laptop. This function enables panning. Panning is often used for scrolling. The ioctl function gives you the power to take advantage of special features other cards don't have. The sky is the limit for defining your ioctl calls.
There exists a default memory map function for fbdev, but sometimes it just doesn't have the power you truly need. A good example of this is video cards that work in sparc workstations that need their own mmap functions because of the way sparcs handle memory is different from other platforms.
This is true even for sparcs with PCI buses. It is intended to initialize the engine or set the accel engine into a state so that you can use the acceleration engine.
It also ensures that the framebuffer is not accessed at the same time as the accel engine. This can lock a system. Usually, there exists a bit to test to see if an accel engine is idle or if the card generates an interrupt. Some cards have separate states for 3D and 2D. This function insures that the card goes into a 2D state. Just in case a previous application set the accel engine into a 3D state or made the accel engine very unhappy. This function sets the video card in a state such that you can write to the framebuffer again.
You should provide both functions if your driver uses even one hardware accelerated function. The reason being is to ensure that the framebuffer is not accessed at the same time as the accel engine. Like the first, they are required. If your card does not support any of these accelerated functions, there exist default functions for packed pixel framebuffer formats. If your driver supports some but not all of the accels available, you can still use some of these software emulated accels.
Each software-emulated accel is stored in a separate file. Now lets describe each accel function. Before we discuss these functions we need to note not to draw in areas pass the video boundaries. If it does, you need to adjust the width and height of the areas to avoid this problem. The first function just fills in a rectangle starting at x1 and y1 of some width and height with a pixel value of packed pixel format.
This allows things like quickly erasing a rectangular area. The other function just directly copies the data. It just copies one area of the framebuffer at source x and source y of some width and height to some destination x and y. This function copies an image from system memory to video memory. You can get really fancy here but this is fbdev, which has the purpose of mode setting only.
All the image blit function does is draw bitmaps, image made of a foreground and background color, and a color image of the same color depth as the framebuffer. The second part is used to draw the little penguins.
The drawing of bitmaps is used to draw our fonts. That does it for the functions. Now you should be set for writing your driver.
The framebuffer console fbcon , as its name implies, is a text console running on top of the framebuffer device. It has the functionality of any standard text console driver, such as the VGA console, with the added features that can be attributed to the graphical nature of the framebuffer. In the x86 architecture, the framebuffer console is optional, and some even treat it as a toy. For other architectures, it is the only available display device, text or graphical.
Enabling the Linux Framebuffer