[LWN Logo]

Date:	Fri, 28 Jan 2000 20:29:19 -0500 (EST)
From:	James A Simmons <jsimmons@acsu.buffalo.edu>
To:	Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: Updated 2.3.x job list (its getting shorter)


> vmalloc(GFP_DMA) is needed for DMA drivers

Will you be able to allocate several megs for DMA? 

> Fbcon races

Working on it. Right now banging head against wall with multihead
problems. The console code doesn't care for multihead systems :(
Good example is scrollback doesn't work if you have more than one
head. Recently we have been discussion the problem of VT switching. With
fbcon it's possible to have each VT at a different resolution plus each
could have a different colormap. Ideally we would want to preserve the
hardware state for the VT we are switching away from and restore the state
of the hardware for the new VT we switched to. The problem is fbcon_switch
like all switching function is only aware of the console we are switching
to. So before fbdev drivers defined their own currcon which was the
console we where on. This trick has some serve problems on multiheaded
systems. By this most fbdev drivers assume currcon is zero which might
belong to another fbdev driver :( The next problem was if the VT switch
migrated from one head to another head. fg_console started to get really
blurry here since both heads are active. It just would be much easier if
we could define 32 VC per framebuffer device. 

> Fix all remaining PCI code to use new resources and enable_Device

fbdev drivers are starting to be updated for this. 

> Some FB drivers check the A000 area and find it busy then bomb out

Hopefully we can work on these card to make them use MMIO regions instead
of the A000 area. Possible io_region_release on explict opening of
/dev/fb and restore on closing. 

Goals for fbdev project:

Finish seperation of fbdev from fbcon. This makes the code smaller and 
easier to write. Ultimately fbdev driver will not need to worry about the
console system. This will also enable the use of /dev/fb with vgacon and
other nice features. Half way done with present kernel. When I finish the
vfb.c rewrite you will see the difference.  

What needs to be done yet.

Introduce a accel wrapper. This way fbdev drivers can use framebuffer
device's accel engine to perform console drawing functions. This
eliminates the problem of latency and eliminates all those fbcon-cfbX
files. 

Since alot of the redundant code from the drivers and fbgen.c can be moved
to fbcon.c and fbmem.c. This will change struct fb_ops by making its
functions more hardware specific. I seen something of the order. 

struct fb_ops {
    /* open/release and usage marking */
    int (*fb_open)(struct fb_info *info, int user);
    int (*fb_release)(struct fb_info *info, int user);
    /* check settable parameters */
    int (*fb_check_var)(struct fb_var_screeninfo *var, void *par);
    /* set the mode */ 
    int (*fb_set_par)(void *par, struct fb_info *info);
    /* set a color register */
    int (*fb_setcolreg)(u_int regno, u_int red, u_int green, u_int blue,
                        u_int transp, struct fb_info *);
    /* clear display */
    void (*fb_blank)(int blank, struct fb_info*);
    /* pan display */
    int (*fb_pan_display)(struct fb_var_screeninfo *var, struct fb_info
*info);
    /* perform fb specific ioctl */
    int (*fb_ioctl)(struct inode *inode, struct file *file, unsigned int
cmd,
                    unsigned long arg, struct fb_info *info);
    /* perform fb specific mmap */
    int (*fb_mmap)(struct fb_info *info, struct file *file, struct
vm_area_struct *vma); 
    /*  A poll function */
    int (*fb_poll)(struct fb_info *info);	
}

Codito, ergo sum - "I code, therefore I am"
James Simmons                                                      (o_
fbdev/gfx developer                                      (o_  (o_ //\
http://www.linux-fbdev.org                              (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/