linuxconsole-dev

Re: [Linux-fbdev-devel] Re: New API

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

On Wed, 14 Nov 2001, Petr Vandrovec wrote:
> On 14 Nov 01 at 11:58, James Simmons wrote:
> >  *      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.

Or the upper layer could take care of that.

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

Re: [Linux-fbdev-devel] New API

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

On Wed, 14 Nov 2001, James Simmons wrote:
> Hi folks. I finally hammered a newer api for framebuffer devices. I
> adapted skeletonfb.c to show it off. Feedback welcomed.

Good news!

>     /*
>      *  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

> static struct fb_info info;
>     /*
>      * This represents the default state of the hardware.
>      */
> static struct xxx_par __initdata current_par;
>
> static u32 xxxfb_pseudo_palette[17];
> static int inverse = 0;

> /**
>  *      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()).

>  *  	xxxfb_setcolreg - REQUIRED function. Sets a color register.

Is this function really required? Imagine static pseudocolor (fixed palette)
hardware.

>     /* Directcolor:
>      *   var->{color}.offset contains start of bitfield
>      *   var->{color}.length contains length of bitfield
>      *   {hardwarespecific} contains width of DAC
>      *   cmap[X] is programmed to (X << red.offset) | (X << green.offset) | (X << blue.offset)
>      *   DAC[X] is programmed to (red, green, blue)

s/DAC/RAMDAC/

>      *
>      * Pseudocolor:
>      *    uses offset = 0 && length = DAC register width.
>      *    var->{color}.offset is 0
>      *    var->{color}.length contains widht of DAC
>      *    cmap is not used
>      *    DAC[X] is programmed to (red, green, blue)

s/DAC/RAMDAC/

>      * Truecolor:
>      *    does not use DAC.
>      *    var->{color}.offset contains start of bitfield
>      *    var->{color}.length contains length of bitfield
>      *    cmap is programmed to (red << red.offset) | (green << green.offset) |
>      *                      (blue << blue.offset) | (transp << transp.offset)
>      *    DAC does not exist

s/DAC/RAMDAC/

Truecolor does have a DAC (even 3 of them :-), but no RAMDAC.

>     /* 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.

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

[Linux-fbdev-devel] New API

[<he...@ho...>]

James Simmons writes:
 > 
 > Hi folks. I finally hammered a newer api for framebuffer devices. I
 > adapted skeletonfb.c to show it off. Feedback welcomed.
 > 
 > /*
 >  * linux/drivers/video/skeletonfb.c -- Skeleton for a frame buffer device
 >  *
 ...
 > /**
 >  *      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, struct fb_image *image) 
 > {
 > }
 
Which bit ordering will be used? Leftmost = MSb (as in console fonts)
or leftmost = LBb (as in XFree, at least in nVidia driver, which I'm
familiar with)?

-- 
Jindrich Makovicka

Re: New API

[Petr V. <VAN...@vc...>]

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...
                                            

New API

[James S. <jsi...@tr...>]

Hi folks. I finally hammered a newer api for framebuffer devices. I
adapted skeletonfb.c to show it off. Feedback welcomed.

/*
 * linux/drivers/video/skeletonfb.c -- Skeleton for a frame buffer device
 *
 *  Modified to new api Jan 2001 by James Simmons (jsi...@tr...)
 *
 *  Created 28 Dec 1997 by Geert Uytterhoeven
 *
 *
 *  I have started rewriting this driver as a example of the upcoming new API
 *  The primary goal is to remove the console code from fbdev and place it
 *  into fbcon.c. This reduces the code and makes writing a new fbdev driver
 *  easy since the author doesn't need to worry about console internals. It
 *  also allows the ability to run fbdev without a console system on top of it.
 *
 *  First the roles of struct fb_info and struct display have changed. Struct
 *  display has gone away. The upper framebuffer console layer only depends on
 *  fb_info. For each framebuffer device when used as a VT console is allocate 
 *  a set of virtual terminals to it. Only one virtual terminal can be active 
 *  per framebuffer device. So I have struct fb_info represent all the data of
 *  the current hardware state of the framebuffer. Meaning the resolution of  
 *  the active VT (the one you're looking at) and other data is stored in the
 *  fb_info struct. When you VT switch the current video state is translated
 *  to a form to be stored by the the higher level console layer to be stored
 *  for that terminal you just switched away from. Then the current video 
 *  state is set to the data values stored in the upper console layer for the
 *  virtual terminal you are switching to. As you can see doing this makes
 *  the con parameter pretty much useless for the fb_ops functions, as it 
 *  should be. Also having fb_var_screeninfo and other data in fb_info pretty 
 *  much eliminates the need for get_fix and get_var. Once all drivers use the
 *  fix, var, and cmap field fbcon can be written around these fields. This
 *  will also eliminate the need to regenerate fb_var_screeninfo and
 *  fb_fix_screeninfo data every time the get_var and get_fix functions are
 *  called as many drivers do now. The fb_var_screeninfo and
 *  fb_fix_screeninfo field in fb_info can be generated just in set_var and
 *  placed into struct fb_info.
 *
 *  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/slab.h>
#include <linux/delay.h>
#include <linux/fb.h>
#include <linux/init.h>

    /*
     *  This is just simple sample code.
     *
     *  No warranty that it actually compiles.
     *  Even less warranty that it actually works :-)
     */

/* 
 * This structure defines the hardware state of the graphics card. Normally
 * you place this in a header file in linux/include/video. This file usually
 * also includes register information. That allows other driver subsystems
 * and userland applications the ability to use the same header file to 
 * avoid duplicate work and easy porting of software. 
 */
struct xxx_par;

/*
 * Here we define the default structs fb_fix_screeninfo and fb_var_screeninfo
 * if we don't use modedb. If we do use modedb see xxxfb_init how to use it
 * to get a fb_var_screeninfo. Otherwise define a default var as well. 
 */
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. The other side 
     *  of the coin is multiple graphics cards that pass data around until
     *  it is finally displayed on one monitor. Such examples are the
     *  voodoo 1 cards and high end NUMA graphics servers. 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 represents the default state of the hardware. 
     */
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*);

/**
 *      xxxfb_check_var - REQUIRED function. Validates a var passed in. 
 *      @var: frame buffer variable screen structure
 *      @info: frame buffer structure that represents a single frame buffer 
 *
 *	Checks to see if the hardware supports the state requested by
 *	var passed in. This function does not alter the hardware state!!! 
 *	This means the data stored in fb_info, par and var, do not change.
 *	Do NOT change these. This function can be called on its own if we
 *	intent to only test a mode and not actually set it. The stuff in 
 *	modedb.c is a example of this. If the var passed in is slightly 
 *	off by what the hardware can support then we alter the var PASSED in
 *	to what we can do. If the hardware doesn't support mode change 
 * 	just return a -EINVAL;
 *
 *	Returns negative errno on error, or zero on success.
 */
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;
    /* ... */
    return 0;	   	
}

/**
 *      xxxfb_set_par - NOT a required function. Alters the hardware state.
 *      @info: frame buffer structure that represents a single frame buffer
 *
 *	Using the fb_var_screeninfo in fb_info we set the resolution of the
 *	this particular framebuffer. This function alters the par AND the
 *	fb_fix_screeninfo stored in fb_info. It doesn't not alter var in 
 *	fb_info since we are using that data. This means we depend on the
 *	data in var inside fb_info to be supported by the hardware. 
 *	xxxfb_check_var is always called before xxxfb_set_par to ensure this.
 *
 */
static void xxxfb_set_par(struct fb_info *info)
{
    struct xxx_par *par = (struct xxx_par *) info->par;
    /* ... */
}

/**
 *  	xxxfb_setcolreg - REQUIRED function. Sets a color register.
 *      @regno: boolean, 0 copy local, 1 get_user() function
 *      @red: frame buffer colormap structure
 *	@green: The green value which can be up to 16 bits wide 
 *	@blue:  The blue value which can be up to 16 bits wide.
 *	@transp: If supported the alpha value which can be up to 16 bits wide.	
 *      @info: frame buffer info structure
 * 
 *  	Set a single color register. The values supplied have a 16 bit
 *  	magnitude which needs to be scaled in this function for the hardware. 
 *	Things to take into consideration are how many color registers, if
 *	any, are supported with the current color visual. With truecolor mode
 *	no color palettes are supported. Here a psuedo palette is created 
 *	which we store the value in pseudo_palette in struct fb_info. For
 *	pseudocolor mode we have a limited color palette. To deal with this
 *	we can program what color is displayed for a particular pixel value.
 *	DirectColor is similar in that we can program each color field. 
 * 
 *	Returns negative errno on error, or zero on success.
 */
static int xxxfb_setcolreg(unsigned regno, unsigned red, unsigned green,
			   unsigned blue, unsigned transp,
			   const struct fb_info *info)
{
    if (regno >= 256)  /* no. of hw registers */
       return 1;
    /*
     * Program hardware... do anything you want with transp
     */

    /* grayscale works only partially under directcolor */
    if (info->var.grayscale) {
       /* grayscale = 0.30*R + 0.59*G + 0.11*B */
       red = green = blue = (red * 77 + green * 151 + blue * 28) >> 8;
    }

    /* Directcolor:
     *   var->{color}.offset contains start of bitfield
     *   var->{color}.length contains length of bitfield
     *   {hardwarespecific} contains width of DAC
     *   cmap[X] is programmed to (X << red.offset) | (X << green.offset) | (X << blue.offset)
     *   DAC[X] is programmed to (red, green, blue)
     *
     * Pseudocolor:
     *    uses offset = 0 && length = DAC register width.
     *    var->{color}.offset is 0
     *    var->{color}.length contains widht of DAC
     *    cmap is not used
     *    DAC[X] is programmed to (red, green, blue)
     * Truecolor:
     *    does not use DAC.
     *    var->{color}.offset contains start of bitfield
     *    var->{color}.length contains length of bitfield
     *    cmap is programmed to (red << red.offset) | (green << green.offset) |
     *                      (blue << blue.offset) | (transp << transp.offset)
     *    DAC does not exist
     */
#define CNVT_TOHW(val,width) ((((val)<<(width))+0x7FFF-(val))>>16)
    switch (info->fix.visual) {
       case FB_VISUAL_TRUECOLOR:
       case FB_VISUAL_PSEUDOCOLOR:
               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);
               break;
       case FB_VISUAL_DIRECTCOLOR:
	       /* example here assumes 8 bit DAC. Might be different 
		* for your hardware */	
               red = CNVT_TOHW(red, 8);       
               green = CNVT_TOHW(green, 8);
               blue = CNVT_TOHW(blue, 8);
               /* hey, there is bug in transp handling... */
               transp = CNVT_TOHW(transp, 8);
               break;
    }
#undef CNVT_TOHW
    /* 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;
    }
    /* ... */
    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,
			     const struct fb_info *info)
{
    /* ... */
    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 != 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
 *
 *      Returns negative errno on error, or zero on success.
 *
 */
static int xxxfb_blank(int blank_mode, const struct fb_info *info)
{
    /* ... */
    return 0;
}

/* ------------ Accelerated Functions --------------------- */

/*
 * We provide our own functions if we have hardware acceleration
 * or non packed pixel format layouts.  
 */

/**
 *      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
 *	@x1: The x and y corrdinates of the upper left hand corner of the 
 *	@y1: 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 rater operation. We can draw the rectangle with a COPY
 *	      of XOR which provides erasing effect. 
 *
 *	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, int x1, int y1, unsigned int width,
                    unsigned int height, unsigned long color, int rop)
{
}

/**
 *      xxxfb_copyarea - REQUIRED function. Can use generic routines if
 *                       non acclerated hardware and packed pixel based.
 *                       Copies on area of the screen to another area.
 *
 *      @info: frame buffer structure that represents a single frame buffer
 *      @sx: The x and y corrdinates of the upper left hand corner of the
 *      @sy: source area on the screen.
 *      @width: How wide the rectangle is we want to copy.
 *      @height: How tall the rectangle is we want to copy.
 *      @dx: The x and y coordinates of the destination area on the screen.
 *
 *      This drawing operation copies a rectangular area from one area of the
 *	screen to another area.
 */
void xxxfb_copyarea(struct fb_info *p, int sx, int sy, unsigned int width,
                         unsigned int height, int dx, int dy)
{
}

/**
 *      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, struct fb_image *image) 
{
}

/* ------------ Hardware Independent Functions ------------ */

    /*
     *  Initialization
     */

int __init xxxfb_init(void)
{
    int retval;	
   
    /* 
     * Here we set the screen_base to the vitrual memory address
     * for the framebuffer. Usually we obtain the resource address
     * from the bus layer and then translate it to virtual memory
     * space via ioremap. Consult ioport.h. 
     */
    info.screen_base = framebuffer_virtual_memory;	
    info.node = -1;
    info.fbops = &xxxfb_ops;
    info.fix = xxxfb_fix;
    info.par = current_par;
    info.pseudo_palette = xxxfb_pseudo_palette;
    info.flags = FBINFO_FLAG_DEFAULT;
    /* This should give a reasonable default video mode */
    if (!mode_option)
	mode_option = "640x480@60";	 	

    retval = fb_find_mode(&info.var, &info, mode_option, NULL, 0, NULL, 8);
  
    if (!retval || retval == 4)
	return -EINVAL;			

    info.cmap = fb_default_cmap(1<<info.var.bits_per_pixel);	
	
    if (register_framebuffer(&info) < 0)
	return -EINVAL;
    printk(KERN_INFO "fb%d: %s frame buffer device\n", GET_FB_IDX(info.node),
	   info.fix.id);

    /* uncomment this if your driver cannot be unloaded */
    /* MOD_INC_USE_COUNT; */
    return 0;
}

    /*
     *  Cleanup
     */

static void __exit xxxfb_cleanup(void)
{
    /*
     *  If your driver supports multiple boards, you should unregister and
     *  clean up all instances.
     */

    unregister_framebuffer(info);
    /* ... */
}

    /*
     *  Setup
     */

/* 
 * Only necessary if your driver takes special options,
 * otherwise we fall back on the generic fb_setup().
 */
int __init xxxfb_setup(char *options)
{
    /* Parse user speficied options (`video=xxxfb:') */
}


/* ------------------------------------------------------------------------- */

    /*
     *  Frame buffer operations
     */

/* If all you need is that - just don't define ->fb_open */
static int xxxfb_open(const struct fb_info *info, int user)
{
    return 0;
}

/* If all you need is that - just don't define ->fb_release */
static int xxxfb_release(const struct fb_info *info, int user)
{
    return 0;
}

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,	   /* optional */	
	fb_setcolreg:	xxxfb_setcolreg,
	fb_blank:	xxxfb_blank,	   /* optional */
	fb_pan_display:	xxxfb_pan_display, /* optional */	
	fb_fillrect:	xxxfb_fillrect,  
	fb_copyarea:	xxxfb_copyarea,  
	fb_imageblit:	xxxfb_imageblit, 
	fb_ioctl:       xxxfb_ioctl,     /* optional */
	fb_mmap:	xxxfb_mmap,      /* optional */	
};

/* ------------------------------------------------------------------------- */


    /*
     *  Modularization
     */

#ifdef MODULE
module_init(xxxfb_init);
module_exit(xxxfb_cleanup);

MODULE_LICENSE("GPL");
#endif /* MODULE */

Re: Driver specific options

[Petr V. <VAN...@vc...>]

On 14 Nov 01 at 9:57, James Simmons wrote:
> > I think that it is much easier to create an
> > 
> > In such case you have much better control over specified options
> > command line, you can parse some options in special way, you can
> > specify fbdev own defaults for fb_info fields, ... And you do not
> > have to change API. But I think that you all know my position very well.
> 
> This is pretty close to what we have in CVS. Of course doing it this way
> means every framebuffer driver needs its own setup function.

It needs it anyway, AFAIK. Or is there some fbdev driver which is
completely PnP? Maybe sbus* driver family, and for them you can create
fb_default_setup(), which will just retry calls to parse general parameter
for every strsep() result. In such case we have small default setup
for PnP framebuffers, and still complicated/unconfigurable framebuffers can
complain on specified unsupported arguments, or accept its own parameters.
                                                Petr Vandrovec
                                                van...@vc...
                                                

Re: Driver specific options

[James S. <jsi...@tr...>]

> I think that it is much easier to create an
> 
> int is_it_a_general_framebuffer_option(struct fb_info* fbi, 
>                  const char* option);
>                 
> and then in driver do:
> 
> while ((this_opt = strsep(&options, ",")) != NULL) {
>    if (!*this_opt) continue;
>    if (is_it_a_general_framebuffer_option(fbi, this_opt)) continue;
>    if (strcmp(this_opt, "....")) ...
> }
> 
> In such case you have much better control over specified options
> command line, you can parse some options in special way, you can
> specify fbdev own defaults for fb_info fields, ... And you do not
> have to change API. But I think that you all know my position very well.

This is pretty close to what we have in CVS. Of course doing it this way
means every framebuffer driver needs its own setup function.

Re: pm3fb (was: pm2fb driver)

[James S. <jsi...@tr...>]

> > - key repeat: does not work well. Only 2 characters can be repeated. Is it
> > a bug, or a default behaviour I can change ?
> 
> Can you describe it more precisely? The key repeat should be the same as
> AT keyboards do.

I bet it is the mk_sound function problem. I have disabled it in the
current CVS. I really need to fix that. Some who I need to intergrate the 
beeper code and as such both the keyboard and beeper code need their own
repeat rates. At present the input driver for the console system only has
one rate setting.

Re: Driver specific options

[Petr V. <VAN...@vc...>]

On 14 Nov 01 at 9:35, James Simmons wrote:
> static struct {
>         const char *name;
>         int (*init)(void);
>         int (*setup)(char*);
> } fb_drivers[] __initdata = {
> 
> to:
> 
> static struct {
>         struct fb_info* (*init)(void);
>         int (*setup)(char*);
> } fb_drivers[] __initdata = {

I think that it is much easier to create an

int is_it_a_general_framebuffer_option(struct fb_info* fbi, 
                 const char* option);
                
and then in driver do:

while ((this_opt = strsep(&options, ",")) != NULL) {
   if (!*this_opt) continue;
   if (is_it_a_general_framebuffer_option(fbi, this_opt)) continue;
   if (strcmp(this_opt, "....")) ...
}

In such case you have much better control over specified options
command line, you can parse some options in special way, you can
specify fbdev own defaults for fb_info fields, ... And you do not
have to change API. But I think that you all know my position very well.
                                        Petr Vandrovec
                                        van...@vc...

Re: Who has a PPC?

[James S. <jsi...@tr...>]

> I did :-)
> 
> But I notice that there was known problems with the serial
> stuff that I _did_ use. So I'll need to try again with
> 2.4.14 as soon as I find some time...

Great :-) Which tree do you use?

As for me I can test ruby on the following devices:

ARM -> ipaq and a Assabet.

Mips -> Sigmarion, Pb1000 Alchemy board.

ix86

I also had a offer for access to a Parisc server and a Alpha.

Driver specific options

[James S. <jsi...@tr...>]

I have started to make "global" options more specific to the driver. For
example to invert the color map. It would be really nice if we asked to
invert the colormap for certain framebuffer drivers. Alot of drivers do
this in their own setup functions. What I was thinking was to put these
"general" options in video_setup and call them from their. This would work
if we can pass strut fb_info to these general functions i.e
fb_invert_cmap(struct fb_info). In order to do this tho I need the struct
fb_info for that frmaebuffer. So I like to suggest for a solution in 2.5.X
is to change 

static struct {
        const char *name;
        int (*init)(void);
        int (*setup)(char*);
} fb_drivers[] __initdata = {

to:

static struct {
        struct fb_info* (*init)(void);
        int (*setup)(char*);
} fb_drivers[] __initdata = {

We don't need the name field since this is already in struct fb_info. What
do you think?

 

Re: Who has a PPC?

[James S. <jsi...@tr...>]

> >Who has tried ruby on a PowerPPC?
> 
> So far I only was able to make sure it compiles the input layer (but the 
> PPC part of the input layer is nearly the same in 2.4 already), for using 
> it I would need a working aty128fb. Unfortunately I have absolutely no time 
> to dig into aty128fb to fix it :-(.

No problem. I have a ati 128 at home. I can convert it tonight. Today I'm
going to work on the Voodoo 1 card. Plus I'm going to add code to make
things more modular. 

TODO for today:

Add code to map a framebuffer to create a new VT.

Make fbcon modular. 


P.S
  Which tree are you using for the PPC?

Re: CVS Tags

[James S. <jsi...@tr...>]

> Well, this is the method Paul turned me onto.  I used to do it they way you
> were before he showed me why tagging *before* the sync made more sense than
> tagging after it.  If this goes against your policy, then we can do it the
> other way...
>
> It just makes more sense this way since when you pull a version by tag, you
> not only get exactly what it was when you synced to that version, you also
> get any local changes that may or may not have been sent back to Linus (or
> whomever - if it's a drop-in against a drop-in :P).
>
> Does this sound good to you?

yes. So we will tag just before a sync up then.

Re: CVS Tags

[M. R. B. <mr...@0x...>]

* James Simmons <jsi...@tr...> on Wed, Nov 14, 2001:

>=20
> So this is the method people want. Actually all the tags I done where done
> right after I synced and tested the tree.
>=20

Well, this is the method Paul turned me onto.  I used to do it they way you
were before he showed me why tagging *before* the sync made more sense than
tagging after it.  If this goes against your policy, then we can do it the
other way...

It just makes more sense this way since when you pull a version by tag, you
not only get exactly what it was when you synced to that version, you also
get any local changes that may or may not have been sent back to Linus (or
whomever - if it's a drop-in against a drop-in :P).

Does this sound good to you?

M. R.

Re: CVS Tags

[James S. <jsi...@tr...>]

> Erm, you're not supposed to tag the current tree, you tag it as soon as
> you're prepared to bump up to the next kernel release.  In this example,
> you wouldn't tag the tree as 2_4_14 until you were ready to make the
> changes to sync the tree to 2.4.15.
> 
> Because of the AGAINST-2.4.x file, it's assumed that CVS HEAD always points
> to that version.

So this is the method people want. Actually all the tags I done where done
right after I synced and tested the tree.

fb_disable_mtrr ?

[James S. <jsi...@tr...>]

Is this funciton used or should we remove it?

Re: [Linux-fbdev-devel] (no subject)

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

On Wed, 14 Nov 2001, Robert Schwebel wrote:
> On Tue, 13 Nov 2001, James Simmons wrote:
> > As some of you know I have been working on a new console system for
> > 2.5.X.
>
> This might be a good opportunity to throw in some remarks from the
> embedded front. I currently have the problem that I would like to attach a
> Displaytech 64128a LCD to an embedded machine running Linux. The problem
> with these displays is that they have their own controller which is
> accessable through an 8 bit parallel port and some control lines, so it
> does not have any memory mappable frame buffer.
>
> Nevertheless, it would be great to write a framebuffer driver for that
> beast, because then I could use all kinds of "normal" libraries ontop of
> that device, e.g. svgalib, Qt-Embedded, MicroWindows or whatsoever. I'm no
> expert in the current FB interface, but it looks to me that there is no
> mechanism for devices like that. I can imagine to write something like the
> virtual vfb driver, but there is still a mechanism missing that can be
> used to tell the driver that the frame is "dirty" and it has to be
> transferred by the driver into the display.
>
> Any ideas how this could be done, either with the existing interface or
> with possible improvements in the new API are welcome.

The method used in vga256fb (fake a frame buffer, use MMU tricks) can be used
here. Search the list archives for more info.

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

Re: [Linux-fbdev-devel] (no subject)

[Robert S. <ro...@sc...>]

Hello James,

On Tue, 13 Nov 2001, James Simmons wrote:
> As some of you know I have been working on a new console system for
> 2.5.X.

This might be a good opportunity to throw in some remarks from the
embedded front. I currently have the problem that I would like to attach a
Displaytech 64128a LCD to an embedded machine running Linux. The problem
with these displays is that they have their own controller which is
accessable through an 8 bit parallel port and some control lines, so it
does not have any memory mappable frame buffer.

Nevertheless, it would be great to write a framebuffer driver for that
beast, because then I could use all kinds of "normal" libraries ontop of
that device, e.g. svgalib, Qt-Embedded, MicroWindows or whatsoever. I'm no
expert in the current FB interface, but it looks to me that there is no
mechanism for devices like that. I can imagine to write something like the
virtual vfb driver, but there is still a mechanism missing that can be
used to tell the driver that the frame is "dirty" and it has to be
transferred by the driver into the display.

Any ideas how this could be done, either with the existing interface or
with possible improvements in the new API are welcome.

Robert
--=20
 +--------------------------------------------------------+
 |             Dipl.-Ing. Robert Schwebel                 |
 | Pengutronix - Linux Solutions for Science and Industry |
 |  Braunschweiger Stra=DFe 79, 31134 Hildesheim, Germany   |
 |     Phone: +49-5121-28619-0  Fax: +49-5121-28619-4     |
 +--------------------------------------------------------+

Re: Who has a PPC?

[Franz S. <Fra...@la...>]

At 01:32 14.11.2001, James Simmons wrote:

>Who has tried ruby on a PowerPPC?

So far I only was able to make sure it compiles the input layer (but the 
PPC part of the input layer is nearly the same in 2.4 already), for using 
it I would need a working aty128fb. Unfortunately I have absolutely no time 
to dig into aty128fb to fix it :-(.

Franz.

Re: ns558.c ans isapnp

[Vojtech P. <vo...@su...>]

On Tue, Nov 13, 2001 at 02:48:53PM -0800, James Simmons wrote:

> I applied various fixes to this file. It now compiles. Now I might of
> applied the wrong fix but it does work. Vojtech?

Looks quite OK.

-- 
Vojtech Pavlik
SuSE Labs

Re: pm3fb (was: pm2fb driver)

[Vojtech P. <vo...@su...>]

On Sat, Nov 10, 2001 at 01:03:12AM +0100, Johann Deneux wrote:
> On Tue, 6 Nov 2001, James Simmons wrote:
> 
> > 
> > > Should we try to summarize all the problems encountered so far ?
> > 
> > Please do. 
> 
> Here is a rough list of the problems I encountered today with the latest
> CVS version:
> - SMP: compiles, but hangs at boot time. No message can be seen, the
> screen just remains black.
> - serial code: failed to compile.
> gcc -D__KERNEL__ -I/home/sf/linuxconsole/linux/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
> -march=i686 -DMODULE -DMODVERSIONS -include
> /home/sf/linuxconsole/linux/include/linux/modversions.h   -c -o
> serial_8250_pci.o serial_8250_pci.c
> serial_8250_pci.c:1079: sizeof applied to an incomplete type
> serial_8250_pci.c:1079: warning: initialization from incompatible pointer
> type
> make[2]: *** [serial_8250_pci.o] Error 1
> 
> However, I guess this problem may simply be a configuration-related
> problems. Why is this file compiled ? I guess it's only needed for
> additional serial  ports using a PCI card. If I am right, I do not think I
> need this. Where is the option to disable this file ? I do not see
> anything PCI-related in the serial driver seection  of the make menuconfig
> step.
> 
> - matrox frame buffer: failed to compile.
> 
> - key repeat: does not work well. Only 2 characters can be repeated. Is it
> a bug, or a default behaviour I can change ?

Can you describe it more precisely? The key repeat should be the same as
AT keyboards do.

> - imPS2: the vertical wheel is inverted (or was it before ?)

Possible. I've fixed this a couple times already, but because USB and
PS/2 mice disagree about the direction, it tends to get messed up ...

> I will try to give more details later. Time to sleep now.

-- 
Vojtech Pavlik
SuSE Labs

Re: Who has a PPC?

[Romain D. <do...@ir...>]

James Simmons wrote:
> 
> Who has tried ruby on a PowerPPC?

I did :-)

But I notice that there was known problems with the serial
stuff that I _did_ use. So I'll need to try again with
2.4.14 as soon as I find some time...

-- 
DOLBEAU Romain               | Nothing is real but the way that I
feel    
ENS Cachan / Ker Lann        | And I feel like going down, down,
down     
Thesard IRISA / CAPS         |   --
Rainbow,                              
dol...@cl...    |                 'Self Portrait'

Re: CVS Tags

[M. R. B. <mr...@0x...>]

* James Simmons <jsi...@tr...> on Tue, Nov 13, 2001:

>=20
> Oops. I forgot to tag them especially since I skipped 2.4.11. Don't use
> 2.4.11. It is a bad tree from Linus. I just tagged the current tree:
>=20
> linux_2_4_14
>=20

Erm, you're not supposed to tag the current tree, you tag it as soon as
you're prepared to bump up to the next kernel release.  In this example,
you wouldn't tag the tree as 2_4_14 until you were ready to make the
changes to sync the tree to 2.4.15.

Because of the AGAINST-2.4.x file, it's assumed that CVS HEAD always points
to that version.

> I tets it and it works. Now to break things again.
> =20

I'm about to remove the linux_2_4_14 tag (it shouldn't break anything).

M. R.

Re: Who has a PPC?

[Adam G. <ad...@ev...>]

I have not tried Ruby on my PPC, but I would be happy to try it.
Something to worry about, though, is that the kernel for PowerPC is
still different enough from the official Linus kernel to potentially 
cause problems.

Right now I'm running -ac, and it works pretty well, but there are
also other branches like -benh that differ more.


I don't really feel like trying very experimental code on this machine,
but if someone has a clean patch, I'll try it.



Adam



On Tue, Nov 13, 2001 at 04:32:13PM -0800, James Simmons wrote:
> 
> Who has tried ruby on a PowerPPC?  
> 
> 
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
> 

Who has a PPC?

[James S. <jsi...@tr...>]

Who has tried ruby on a PowerPPC?