From: James S. <jsi...@tr...> - 2001-11-14 21:52:02
|
> > Hi folks. I finally hammered a newer api for framebuffer devices. I > > adapted skeletonfb.c to show it off. Feedback welcomed. > > Good news! A few drivers have been converted over to it :-) > > /* > > * If your driver supports multiple boards, you should make these > > * arrays, or allocate them dynamically (using kmalloc()). > > */ > > Perhaps make it more clear that this applies to all 3 (4?) variables below I should. In reality all of them can be dynamically allocated. > > /** > > * xxxfb_check_var - REQUIRED function. Validates a var passed in. > > Is this function really required? Imagine a graphics card with a fixed > resolution (e.g. old Sun3 bwtwo), or vesafb/offb. > > If it's NULL, you cannot change var, and upper layer can check that an > identical var was passed (using memcmp()). Wait. Your right. In CVS I made it optional. I missed updating this. If you can change the mode it just returns the current mode instead. if (!info->fbops->fb_check_var) { *var = info->var; return 0; } > > * xxxfb_setcolreg - REQUIRED function. Sets a color register. > > Is this function really required? Imagine static pseudocolor (fixed palette) > hardware. I never thought about that. Your right. Will fix. > > /* Truecolor has hardware independent palette */ > > if (info->fix.visual == FB_VISUAL_TRUECOLOR) { > > u32 v; > > > > if (regno >= 16) > > return 1; > > > > v = (red << info->var.red.offset) | > > (green << info->var.green.offset) | > > (blue << info->var.blue.offset) | > > (transp << info->var.transp.offset); > > if (info->var.bits_per_pixel == 16) > > ((u16*)(info->pseudo_palette))[regno] = v; > > else > > ((u32*)(info->pseudo_palette))[regno] = v; > > return 0; > > What about info->var.bits_per_pixel == 8? Some handhelds are RGB332 truecolor. Your right again. Even the Matrox millenium could do this mode. I will add as a example. Made changes to skeletonfb.c. |