From: Petr V. <VAN...@vc...> - 2001-11-14 20:24:33
|
On 14 Nov 01 at 11:58, James Simmons wrote: > Hi folks. I finally hammered a newer api for framebuffer devices. I > adapted skeletonfb.c to show it off. Feedback welcomed. Thanks. > * Blank the screen if blank_mode != 0, 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: > * blank_mode == 2: suspend vsync > * blank_mode == 3: suspend hsync > * blank_mode == 4: powerdown What about: * Note: If screen is blanked, all other functions (setcolreg, * imageblit) may be still invoked, and must work. This needs * special care if you are blanking by programming DAC to all black. or something like that. > * Returns negative errno on error, or zero on success. If driver does not support specified powerdown mode, should it use nearest mode with greater power consumption, nearest mode with smaller power consumption, or should it report an error? > /* > * We provide our own functions if we have hardware acceleration > * or non packed pixel format layouts. ? * If we have no hardware acceleration, we provide an unaccelerated ? * functions in fbcon-cfb*.c modules. You can use these functions ? * as fallbacks if hardware unsupported action is requested. > * xxxfb_fillrect - REQUIRED function. Can use generic routines if > * non acclerated hardware and packed pixel based. > * Draws a rectangle on the screen. filled rectangle, I assume, not two horizontal and two vertical lines... > * > * @info: frame buffer structure that represents a single frame buffer > #ifdef MODULE > module_init(xxxfb_init); > module_exit(xxxfb_cleanup); > > MODULE_LICENSE("GPL"); > #endif /* MODULE */ Move #endif up below xxxfb_init, as these macros works correctly when code is built into kernel, and we want to make sure that nobody will remove #ifdef MODULE when doing cleanup, as we still call init explicitly from global fb initialization. I do not need it on my systems (due to pciorder patch), but others may use non-PCI devices, so we probably want to retain this :-( Unless there is another devices ordering scheme planned for 2.5. Petr Vandrovec van...@vc... |