Re: [linux-fbdev] New api again

[Geert U. <ge...@li...>]

On Tue, 16 Jan 2001, James Simmons wrote:
>     Since 2.4 is now out and the new console system is becoming stable its
> time to discuss the new api for fbcon again. I updated skeletonfb for a
> example and posted here. Feel free to addd input to the design.
> 
> /*
>  * linux/drivers/video/skeletonfb.c -- Skeleton for a frame buffer device
>  *
>  *  Modified to new api Jan 2001 by James Simmons (jsi...@li...)
>  *
>  *  Created 28 Dec 1997 by Geert Uytterhoeven
>  *
>  * This file is subject to the terms and conditions of the GNU General Public
>  * License.  See the file COPYING in the main directory of this archive
>  * for more details.
>  */
> 
> #include <linux/module.h>
> #include <linux/kernel.h>
> #include <linux/errno.h>
> #include <linux/string.h>
> #include <linux/mm.h>
> #include <linux/tty.h>
> #include <linux/malloc.h>
> #include <linux/delay.h>
> #include <linux/fb.h>
> #include <linux/init.h>
> 
> /* This header contains struct xxx_par for your graphics card */
> #include <video/skeletion.h>
> 
>     /*
>      *  This is just simple sample code.
>      *
>      *  No warranty that it actually compiles.
>      *  Even less warranty that it actually works :-)
>      */
> 
> static struct fb_fix_screeninfo xxxfb_fix __initdata = {
>     "FB's name", (unsigned long) NULL, 0, FB_TYPE_PACKED_PIXELS, 0,
>     FB_VISUAL_PSEUDOCOLOR, 1, 1, 1, 0, (unsigned long) NULL, 0, FB_ACCEL_NONE
> };
> 
>     /*
>      * 	Modern graphical hardware not only supports pipelines but some 
>      *  also support multiple monitors where each display can have its  
>      *  its own unique data. In this case each display could be  
>      *  represented by a seperate framebuffer device thus a seperate 
>      *  struct fb_info. In this case all of the par structures for the
>      *  graphics card would be shared between each struct fb_info. This
>      *  allows when one display changes it video resolution (info->var) 
>      *  the other displays know instantly. Each display can always be
>      *  aware of the entire hardware state that affects it. I hope this 
>      *  covers every possible hardware design. If not feel free to send 
>      *  me more design types. 
>      */
> 
>     /*
>      *  If your driver supports multiple boards, you should make these  
>      *  arrays, or allocate them dynamically (using kmalloc()). 
>      */ 
> static struct fb_info info;
>     /* 
>      * This struct represents the state of a rendering pipe. A modern 
>      * graphics card can have more than one pipe per card depending 
>      * on the hardware design. So the same holds true if you have
>      * multiple pipes. Use arrays or allocate them dynamically.
>      *
>      * Read video/skeleton.h for more information about graphics pipes. 
>      */
> static struct xxx_par __initdata current_par;
> 
> static u32 xxxfb_pseudo_palette[17];
> static int inverse = 0;
> 
> int xxxfb_init(void);
> int xxxfb_setup(char*);
> 
> /* ------------------- chipset specific functions -------------------------- */
> 
> static int xxxfb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
> {
>     const struct xxx_par *par = (const struct xxx_par *) info->par;
>     /* 
>      * We test to see if the hardware can support var. Struct xxx_par will
>      * have the information needed to see if it does. Note we don't change
>      * par nor info->var. This function can be called on its own if we
>      * intent to only test a mode and not set it. Return 0 if it is a
>      * acceptable mode.
>      */
> 
>     /* ... */
>     return 0;	   	
> }
> 
> static void xxxfb_set_par(struct fb_info *info)
> {
>     /*
>      *  xxx_fb_check_var tested the mode we want to set the hardware to.
>      *  If it passes it then is set to info->var. Now we set the hardware
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Who sets this? fbmem.c? Or is there a var argument missing for this function?

>      *  (and struct par) according to info->var.
>      */
> 
>     /* ... */
> }

I think it's still safer to use one function for both testing and setting,
since for multi-headed cards both heads depend on each other:

    check_and_test(var, info, test_only)
    {
	get_lock() /* multi-headed cards only */
	... do test ...

	if (test_only) {
	    release_lock() /* multi-headed cards only */
	    return;
	}

	... do set ...
	release_lock() /* multi-headed cards only */
    }

> void xxxfb_imageblit(struct fb_info *p, unsigned int width,
>                      unsigned int height, unsigned long *image,
>                      int image_depth, int dx, int dy)
> {
> }

I still like to have the possibility to blit an array of images, for drawing
multiple characters (fbcon_putcs()). Drawing individual characters is too slow
on some hardware (e.g. Amiga bitplanes: each 8-pixel wide character needs to
access 1 byte in each plane, while drawing 4 (AGA, 32-bit wide bus) or 2 (ECS,
16-bit wide bus) characters needs the same number of memory accesses.

>     /* This should give a reasonable default video mode */
>     if (!mode_option)
> 	mode_option = "640x480@60";	 	

Not needed. fb_find_mode() will do this automagically if mode_option is NULL.

> static struct fb_ops xxxfb_ops = {
> 	owner:		THIS_MODULE,
> 	fb_open:	xxxfb_open,    /* only if you need it to do something */
> 	fb_release:	xxxfb_release, /* only if you need it to do something */
> 	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_rectfill:	xxxfb_rectfill,  /* optional */
> 	fb_copyarea:	xxxfb_copyarea,  /* optional */
> 	fb_imageblit:	xxxfb_imageblit, /* optional */
> 	fb_ioctl:       xxxfb_ioctl,     /* optional */
> 	fb_mmap:	xxxfb_mmap,      /* optional */	
> };

Aren't xxxfb_{rectfill,copyarea,imageblit} mandatory, because fbcon-* will go
away?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds