Thread (3 messages) 3 messages, 3 authors, 2004-11-08

Re: Framebuffer Port guide for 2.4->2.6?

From: Antonino A. Daplas <hidden>
Date: 2004-11-04 01:50:08

On Thursday 04 November 2004 03:11, Kelly Price wrote:
Is there a port guide for framebuffer drivers going from 2.4 to 2.6?
I'm trying to port the CT65548 Frambuffer driver over to 2.6.

http://members.elysium.pl/ytm/html/linux.html is where the 2.4 version
is at.
Can you just add the chip support to the chipsfb driver which currently
supports CT 65550, or are the chipsets too different that they deserve
different drivers?

Anyway there are a scarcity of documentation about the framebuffer system,
especially in 2.6.  So here's a start:

In general, you need to allocate:

struct fb_info - structure that acts as a glue between the console, userspace
and driver

void *fb_info.par = xxxfb_par - struct that is private to the driver:

The above are the only data that the driver needs to access in order to
function correctly.

Your xxxfb_init() function must be module_init().  No need to alter other
files except the Makefile and Kconfig.

In general start your xxxfb_init() function with this:

if (fb_get_options("chipsfb", NULL))
	return -ENODEV

Or if the driver needs to parse options with xxxfb_setup(), then

	char *option = NULL;

	if (fb_get_options("chipsfb", &option))
		return -ENODEV;
	xxxfb_setup(option);

int __init xxxfb_init(void) {
	struct xxxfb_par *par;
	struct fb_info *info;

	... call fb_get_options() here;

	... allocate the driver structures
	info = framebuffer_alloc(sizeof(struct xxxfb_par));
	... check for errors
	par = info->par;

	... do your stuff here, allocation of resources, etc;
	xxx

	... then fill up the fb_info structure, very important:
	info->fbops = xxxfb_ops;
	info->var = xxxfb_var; /* the mode the driver will boot into */
	info->fix = xxxfb_fix; /* the fix struct the driver will boot into */
	info->screen_base = xxx; /* the virtual address of the framebuffer */
	fb_alloc_cmap(&info->cmap, 256, 0); /* 256 is a generally safe value*/
	info->flags = FBINFO_DEFAULT | other options; /* not very important */

	... finally register the framebuffer
	register_framebuffer(info);
	
	... and exit
	return 0;
}

struct fb_ops xxxfb_ops;

1. In 2.4, the drawing function are in struct display->dispsw = fbcon_cfb* or
ct48b_accel.  This is gone now, instead, the following hooks in struct fb_ops
are used instead:

fb_imageblit (required)
fb_copyarea (required)
fb_fillrect (required)
fb_cursor (required)

The generic versions are:

cfb_imageblit - used by the putc, putcs methods and logo drawing
cfb_copyarea - used by the bmove method
cfb_fillrect - used by the clear, clear_margins methods
soft_cursor - the cursor method

They will work correctly as long as the driver is in packed-pixel mode at
whatever bpp. soft_cursor will always work.

Test your driver with the generic functions, then you can write your own
hardware implementation.

2. The 2.4 version set_var is split into 2: 

fb_check_var (optional);
fb_set_par (optional);

2.a In fb_check_var, the driver will be passed with a var structure and all
the driver needs to do is check the contents and can do the following:

  a. alter the contents of the var to fit the hardware capability
  b. return -EINVAL if any of the fields in var does not fit the hardware

The first is the preferred response.

2.b In fb_set_par, the driver will actually modify the hardware according to
the contents of info->var _only_.  This is important.

3. fb_setcolreg (optional)

Not very different from the 2.4 version except that info->pseudo_palette
needs to be filled up if in directcolor or truecolor mode.  Also, if using
the generic cfb_* drawing functions, the pseudo_palette is always (u32 *).
The pseudo_palette must be a minimum of 16 entries. The pseudo_palette is
the same as 2.4' s display->dispsw_data.

4. fb_pan_display(optional)
optional function, not too different from the 2.4 version.

5. fb_sync (optional unless the driver has hardware accelerated drawing)
wait for engine idle (blit idle usually)   

6. fb_blank, fb_ioctl, fb_mmap are optional.

Note that the get_fix, get_var, set_var, getcolreg hooks in 2.4 are
gone in 2.6.

If you have further questions, just write to this list.

Tony




-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help