From: "Antonino A. Daplas" <adaplas@hotpop.com>
To: linux-fbdev-devel@lists.sourceforge.net,
Kelly Price <tygris@cablespeed.com>
Subject: Re: Framebuffer Port guide for 2.4->2.6?
Date: Thu, 4 Nov 2004 09:46:45 +0800 [thread overview]
Message-ID: <200411040946.45502.adaplas@hotpop.com> (raw)
In-Reply-To: <41892D53.1060007@cablespeed.com>
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
next prev parent reply other threads:[~2004-11-04 1:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-03 19:11 Framebuffer Port guide for 2.4->2.6? Kelly Price
2004-11-04 1:46 ` Antonino A. Daplas [this message]
2004-11-08 13:33 ` Dermot Bradley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200411040946.45502.adaplas@hotpop.com \
--to=adaplas@hotpop.com \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=tygris@cablespeed.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.