skeletonfb.c
来自「Linux环境下视频显示卡设备的驱动程序源代码」· C语言 代码 · 共 1,037 行 · 第 1/3 页
C
1,037 行
* and higher than that, true/directcolor. This is incorrect, one needs * to look at the fix->visual. * * Another common mistake is using bits_per_pixel to calculate the color * depth. The bits_per_pixel field does not directly translate to color * depth. You have to compute for the color depth (using the color * bitfields) and fix->visual as seen above. */ /* * This is the point where the color is converted to something that * is acceptable by the hardware. */#define CNVT_TOHW(val,width) ((((val)<<(width))+0x7FFF-(val))>>16) red = CNVT_TOHW(red, info->var.red.length); green = CNVT_TOHW(green, info->var.green.length); blue = CNVT_TOHW(blue, info->var.blue.length); transp = CNVT_TOHW(transp, info->var.transp.length);#undef CNVT_TOHW /* * This is the point where the function feeds the color to the hardware * palette after converting the colors to something acceptable by * the hardware. Note, only FB_VISUAL_DIRECTCOLOR and * FB_VISUAL_PSEUDOCOLOR visuals need to write to the hardware palette. * If you have code that writes to the hardware CLUT, and it's not * any of the above visuals, then you are doing something wrong. */ if (info->fix.visual == FB_VISUAL_DIRECTCOLOR || info->fix.visual == FB_VISUAL_TRUECOLOR) write_{red|green|blue|transp}_to_clut(); /* This is the point were you need to fill up the contents of * info->pseudo_palette. This structure is used _only_ by fbcon, thus * it only contains 16 entries to match the number of colors supported * by the console. The pseudo_palette is used only if the visual is * in directcolor or truecolor mode. With other visuals, the * pseudo_palette is not used. (This might change in the future.) * * The contents of the pseudo_palette is in raw pixel format. Ie, each * entry can be written directly to the framebuffer without any conversion. * The pseudo_palette is (void *). However, if using the generic * drawing functions (cfb_imageblit, cfb_fillrect), the pseudo_palette * must be casted to (u32 *) _regardless_ of the bits per pixel. If the * driver is using its own drawing functions, then it can use whatever * size it wants. */ if (info->fix.visual == FB_VISUAL_TRUECOLOR || info->fix.visual == FB_VISUAL_DIRECTCOLOR) { u32 v; if (regno >= 16) return -EINVAL; v = (red << info->var.red.offset) | (green << info->var.green.offset) | (blue << info->var.blue.offset) | (transp << info->var.transp.offset); ((u32*)(info->pseudo_palette))[regno] = v; } /* ... */ return 0;}/** * xxxfb_pan_display - NOT a required function. Pans the display. * @var: frame buffer variable screen structure * @info: frame buffer structure that represents a single frame buffer * * Pan (or wrap, depending on the `vmode' field) the display using the * `xoffset' and `yoffset' fields of the `var' structure. * If the values don't fit, return -EINVAL. * * Returns negative errno on error, or zero on success. */static int xxxfb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info){ /* * If your hardware does not support panning, _do_ _not_ implement this * function. Creating a dummy function will just confuse user apps. */ /* * Note that even if this function is fully functional, a setting of * 0 in both xpanstep and ypanstep means that this function will never * get called. */ /* ... */ return 0;}/** * xxxfb_blank - NOT a required function. Blanks the display. * @blank_mode: the blank mode we want. * @info: frame buffer structure that represents a single frame buffer * * Blank the screen if blank_mode != FB_BLANK_UNBLANK, else unblank. * Return 0 if blanking succeeded, != 0 if un-/blanking failed due to * e.g. a video mode which doesn't support it. * * Implements VESA suspend and powerdown modes on hardware that supports * disabling hsync/vsync: * * FB_BLANK_NORMAL = display is blanked, syncs are on. * FB_BLANK_HSYNC_SUSPEND = hsync off * FB_BLANK_VSYNC_SUSPEND = vsync off * FB_BLANK_POWERDOWN = hsync and vsync off * * If implementing this function, at least support FB_BLANK_UNBLANK. * Return !0 for any modes that are unimplemented. * */static int xxxfb_blank(int blank_mode, struct fb_info *info){ /* ... */ return 0;}/* ------------ Accelerated Functions --------------------- *//* * We provide our own functions if we have hardware acceleration * or non packed pixel format layouts. If we have no hardware * acceleration, we can use a generic unaccelerated function. If using * a pack pixel format just use the functions in cfb_*.c. Each file * has one of the three different accel functions we support. *//** * xxxfb_fillrect - REQUIRED function. Can use generic routines if * non acclerated hardware and packed pixel based. * Draws a rectangle on the screen. * * @info: frame buffer structure that represents a single frame buffer * @region: The structure representing the rectangular region we * wish to draw to. * * This drawing operation places/removes a retangle on the screen * depending on the rastering operation with the value of color which * is in the current color depth format. */void xxxfb_fillrect(struct fb_info *p, const struct fb_fillrect *region){/* Meaning of struct fb_fillrect * * @dx: The x and y corrdinates of the upper left hand corner of the * @dy: area we want to draw to. * @width: How wide the rectangle is we want to draw. * @height: How tall the rectangle is we want to draw. * @color: The color to fill in the rectangle with. * @rop: The raster operation. We can draw the rectangle with a COPY * of XOR which provides erasing effect. */}/** * xxxfb_copyarea - REQUIRED function. Can use generic routines if * non acclerated hardware and packed pixel based. * Copies one area of the screen to another area. * * @info: frame buffer structure that represents a single frame buffer * @area: Structure providing the data to copy the framebuffer contents * from one region to another. * * This drawing operation copies a rectangular area from one area of the * screen to another area. */void xxxfb_copyarea(struct fb_info *p, const struct fb_copyarea *area) {/* * @dx: The x and y coordinates of the upper left hand corner of the * @dy: destination area on the screen. * @width: How wide the rectangle is we want to copy. * @height: How tall the rectangle is we want to copy. * @sx: The x and y coordinates of the upper left hand corner of the * @sy: source area on the screen. */}/** * xxxfb_imageblit - REQUIRED function. Can use generic routines if * non acclerated hardware and packed pixel based. * Copies a image from system memory to the screen. * * @info: frame buffer structure that represents a single frame buffer * @image: structure defining the image. * * This drawing operation draws a image on the screen. It can be a * mono image (needed for font handling) or a color image (needed for * tux). */void xxxfb_imageblit(struct fb_info *p, const struct fb_image *image) {/* * @dx: The x and y coordinates of the upper left hand corner of the * @dy: destination area to place the image on the screen. * @width: How wide the image is we want to copy. * @height: How tall the image is we want to copy. * @fg_color: For mono bitmap images this is color data for * @bg_color: the foreground and background of the image to * write directly to the frmaebuffer. * @depth: How many bits represent a single pixel for this image. * @data: The actual data used to construct the image on the display. * @cmap: The colormap used for color images. *//* * The generic function, cfb_imageblit, expects that the bitmap scanlines are * padded to the next byte. Most hardware accelerators may require padding to * the next u16 or the next u32. If that is the case, the driver can specify * this by setting info->pixmap.scan_align = 2 or 4. See a more * comprehensive description of the pixmap below. */}/** * xxxfb_cursor - OPTIONAL. If your hardware lacks support * for a cursor, leave this field NULL. * * @info: frame buffer structure that represents a single frame buffer * @cursor: structure defining the cursor to draw. * * This operation is used to set or alter the properities of the * cursor. * * Returns negative errno on error, or zero on success. */int xxxfb_cursor(struct fb_info *info, struct fb_cursor *cursor){/* * @set: Which fields we are altering in struct fb_cursor * @enable: Disable or enable the cursor * @rop: The bit operation we want to do. * @mask: This is the cursor mask bitmap. * @dest: A image of the area we are going to display the cursor. * Used internally by the driver. * @hot: The hot spot. * @image: The actual data for the cursor image. * * NOTES ON FLAGS (cursor->set): * * FB_CUR_SETIMAGE - the cursor image has changed (cursor->image.data) * FB_CUR_SETPOS - the cursor position has changed (cursor->image.dx|dy) * FB_CUR_SETHOT - the cursor hot spot has changed (cursor->hot.dx|dy) * FB_CUR_SETCMAP - the cursor colors has changed (cursor->fg_color|bg_color) * FB_CUR_SETSHAPE - the cursor bitmask has changed (cursor->mask) * FB_CUR_SETSIZE - the cursor size has changed (cursor->width|height) * FB_CUR_SETALL - everything has changed * * NOTES ON ROPs (cursor->rop, Raster Operation) * * ROP_XOR - cursor->image.data XOR cursor->mask * ROP_COPY - curosr->image.data AND cursor->mask * * OTHER NOTES: * * - fbcon only supports a 2-color cursor (cursor->image.depth = 1) * - The fb_cursor structure, @cursor, _will_ always contain valid * fields, whether any particular bitfields in cursor->set is set * or not. */}/** * xxxfb_rotate - NOT a required function. If your hardware * supports rotation the whole screen then * you would provide a hook for this. * * @info: frame buffer structure that represents a single frame buffer * @angle: The angle we rotate the screen. * * This operation is used to set or alter the properities of the * cursor. */void xxxfb_rotate(struct fb_info *info, int angle){/* Will be deprecated */}/** * xxxfb_sync - NOT a required function. Normally the accel engine * for a graphics card take a specific amount of time. * Often we have to wait for the accelerator to finish * its operation before we can write to the framebuffer * so we can have consistent display output. * * @info: frame buffer structure that represents a single frame buffer * * If the driver has implemented its own hardware-based drawing function, * implementing this function is highly recommended. */int xxxfb_sync(struct fb_info *info){ return 0;} /* * Frame buffer operations */static struct fb_ops xxxfb_ops = { .owner = THIS_MODULE, .fb_open = xxxfb_open, .fb_read = xxxfb_read, .fb_write = xxxfb_write, .fb_release = xxxfb_release, .fb_check_var = xxxfb_check_var, .fb_set_par = xxxfb_set_par, .fb_setcolreg = xxxfb_setcolreg, .fb_blank = xxxfb_blank, .fb_pan_display = xxxfb_pan_display, .fb_fillrect = xxxfb_fillrect, /* Needed !!! */ .fb_copyarea = xxxfb_copyarea, /* Needed !!! */ .fb_imageblit = xxxfb_imageblit, /* Needed !!! */ .fb_cursor = xxxfb_cursor, /* Optional !!! */ .fb_rotate = xxxfb_rotate, .fb_sync = xxxfb_sync, .fb_ioctl = xxxfb_ioctl, .fb_mmap = xxxfb_mmap,};/* ------------------------------------------------------------------------- */ /* * Initialization *//* static int __init xxfb_probe (struct platform_device *pdev) -- for platform devs */static int __devinit xxxfb_probe(struct pci_dev *dev, const struct pci_device_id *ent){ struct fb_info *info; struct xxx_par *par; struct device *device = &dev->dev; /* or &pdev->dev */ int cmap_len, retval; /* * Dynamically allocate info and par */ info = framebuffer_alloc(sizeof(struct xxx_par), device); if (!info) {
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?