视频播放魔法师与兔子时，出现死机
Internal error: Oops: 817 [#1] PREEMPT
Modules linked in: dm9000_con201 ipsec key led
CPU: 0 Not tainted (2.6.24.7 #168)
PC is at logo_linux_landscaped_clut224_data+0x1e997/0x5dc03
LR is at generic_write_checks+0x203/0x2a8
pc : [<c0056ac0>] lr : [<c00d79bf>] psr: 80000193
sp : c6c99f58 ip : c6c99f58 fp : c6c99f74
r10: 001c27c8 r9 : c6c98000 r8 : 00000000
r7 : 00000001 r6 : c6a9a920 r5 : 00000047 r4 : c04c5508
r3 : 393660a8 r2 : 0001869f r1 : c04c5508 r0 : 00000047
Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
Control: 00c5387f Table: 56b7c008 DAC: 00000015
Process Xorg (pid: 1048, stack limit = 0xc6c98260)
Stack: (0xc6c99f58 to 0xc6c9a000)
9f40: 00000000 00000003
9f60: 00000000 00000001 c6c99f8c c6c99f78 c00a7768 c00d69cc c04c45b8 00000001
9f80: c6c99fac c6c99f90 c0098044 c00a7720 ffffffff f4700000 00000002 00000001
9fa0: 00000000 c6c99fb0 c0098cc4 c009800c 00000014 00000068 00000168 08820882
9fc0: 00000014 00000000 407ee418 00000127 40703410 407ee418 001c27c8 000000ef
9fe0: 0000001b beb8f8d8 40703410 4068360c 80000010 ffffffff 00000000 00000000
Backtrace:
[<c00d69c0>] (handle_level_irq+0x0/0x170) from [<c00a7768>]
(s3c_irq_demux_eint4_11+0x54/0x70)
r7:00000001 r6:00000000 r5:00000003 r4:00000000
[<c00a7714>] (s3c_irq_demux_eint4_11+0x0/0x70) from [<c0098044>]
(__exception_text_start+0x44/0x60)
r5:00000001 r4:c04c45b8
[<c0098000>] (__exception_text_start+0x0/0x60) from [<c0098cc4>]
(__irq_usr+0x44/0xa0)
Exception stack(0xc6c99fb0 to 0xc6c99ff8)
9fa0: 00000014 00000068 00000168 08820882
9fc0: 00000014 00000000 407ee418 00000127 40703410 407ee418 001c27c8 000000ef
9fe0: 0000001b beb8f8d8 40703410 4068360c 80000010 ffffffff
r7:00000001 r6:00000002 r5:f4700000 r4:ffffffff
Code: cc94a9d5 3e558124 106c34c8 b5ee9f07 (45e0939a)
Kernel panic - not syncing: Fatal exception in interrupt
==============================================
视频播放魔法师与兔子时，出现死机，现象比较固定
++++++++++++++++++++++++++++++++++++++++++++++
Boot Logo
A popular feature offered by the frame buffer subsystem is the boot logo. To display a logo, enable CONFIG_LOGO during kernel configuration and select an available logo. You may also add a custom logo image in the drivers/video/logo/ directory.
CLUT224 is a commonly used boot logo image format that supports 224 colors. The working of this format is similar to pseudo palettes described in the section "Color Modes." A CLUT224 image is a C file containing two structures:
-
A CLUT (Color Look Up Table), which is a character array of 224 RGB tuples (thus having a size of 224*3 bytes). Each 3-byte CLUT element is a combination of red, green, and blue colors.
-
A data array whose each byte is an index into the CLUT. The indices start at 32 and extend until 255 (thus supporting 224 colors). Index 32 refers to the first element in the CLUT. The logo manipulation code (in drivers/video/fbmem.c) creates frame buffer pixel data from the CLUT tuple corresponding to each index in the data array. Image display is accomplished using the low-level frame buffer driver's fb_imageblit() method, as indicated in the section "Accelerated Methods."
Other supported logo formats are the 16-color vga16 and the black-and-white mono. Scripts are available in the top-level scripts/ directory to convert standard Portable Pixel Map (PPM) files to the supported logo formats.
If the frame buffer device is also the console, boot messages scroll under the logo. You may prefer to disable console messages on production-level systems (by adding console=/dev/null to the kernel command line) and display a customer-supplied CLUT224 "splash screen" image as the boot logo.
Color Modes
Common color modes supported by video hardware include pseudo color and true color. In the former, index numbers are mapped to RGB pixel encodings. By choosing a subset of available colors and by using the indices corresponding to the colors instead of the pixel values themselves, you can reduce demands on frame buffer memory. Your hardware needs to support this scheme of a modifiable color set (or palette), however.
In true color mode (which is what our example LCD controller supports), modifiable palettes are not relevant. However, you still have to satisfy the demands of the frame buffer console driver, which uses only 16 colors. For this, you have to create a pseudo palette by encoding the corresponding 16 raw RGB values into bits that can be directly fed to the hardware. This pseudo palette is stored in the pseudo_palette field of the fb_info structure. In Listing 12.2, myfb_setcolreg() populates it as follows:
((u32*)(info->pseudo_palette))[color_index] =
(red << info->var.red.offset) |
(green << info->var.green.offset) |
(blue << info->var.blue.offset) |
(transp << info->var.transp.offset);
Our LCD controller uses 16 bits per pixel and the RGB565 format, so as you saw earlier, the fb_check_var() method ensures that the red, green and blue values reside at bit offsets 11, 5, and 0, respectively. In addition to the color index and the red, blue, and green values, fb_setcolreg() takes in an argument transp, to specify desired transparency effects. This mechanism, called alpha blending, combines the specified pixel value with the background color. The LCD controller in this example does not support alpha blending, so myfb_check_var() sets the transp offset and length to zero.
The frame buffer abstraction is powerful enough to insulate applications from the characteristics of the display panel—whether it's RGB or BGR or something else. The red, blue, and green offsets set by fb_check_var() percolate to user space via the fb_var_screeninfo structure populated by the FBIOGET_VSCREENINFO ioctl(). Because applications such as X Windows are frame buffer-compliant, they paint pixels into the frame buffer according to the color offsets returned by this ioctl().
Bit lengths used by the RGB encoding (5+6+5=16 in this case) is called the color depth, which is used by the frame buffer console driver to choose the logo file to display during boot (see the section "Boot Logo").
Accelerated Methods
If your user interface needs to perform heavy-duty video operations such as blending, stretching, moving bitmaps, or dynamic gradient generation, you likely require graphics acceleration to obtain acceptable performance. Let's briefly visit the fb_ops methods that you can leverage if your video hardware supports graphics acceleration.
The fb_imageblit() method draws an image to the display. This entry point provides an opportunity to your driver to leverage any special capabilities that your video controller might possess to hasten this operation. cfb_imageblit() is a generic library function provided by the frame buffer core to achieve this if you have nonaccelerated hardware. It's used, for instance, to output a logo to the screen during boot up. fb_copyarea() copies a rectangular area from one screen region to another. cfb_copyarea() provides an optimized way of doing this if your graphics controller does not possess any magic to accelerate this operation. The fb_fillrect() method speedily fills a rectangle with pixel lines. cfb_fillrect() offers a generic non-accelerated way to achieve this. The LCD controller in our navigation system does not provide for acceleration, so the example driver populates these methods using the generic software-optimized routines offered by the frame buffer core.
DirectFBDirectFB (www.directfb.org) is a library built on top of the frame buffer interface that provides a simple window manager framework and hooks for hardware graphics acceleration and virtual interfaces that allow coexistence of multiple frame buffer applications. DirectFB, along with an accelerated frame buffer device driver downstream and a DirectFB-aware rendering engine such as Cairo (www.cairographics.org) upstream, is sometimes used on graphics-intensive embedded devices instead of more traditional solutions such as X Windows. |