I think kmalloc() is the best thing for vgb. Vfb is just meant to be a sample
driver, so the limitation to 128 KB is not that important. It's more important
that you can actually mmap() it from user space, which is not possible with
vmalloc().
> to also show a good example of the use of par. All fbdev driver writers
I'm afraid there's not much `par' to show in vfb, unless you invent some fake
registers that have to be set up... Hmm, why not do that?
Another thing: to avoid flicker and to avoid expensive PCI bus accesses, it can
be useful to check whether you really have to write a register value. If your
`par' looks sufficiently like the real hardware registers, you can define
static inline __set_reg(unsigned long reg, u32 val, u32 *oldval)
{
if (val != *oldval) {
real_set_reg(reg, val);
*oldval = val);
}
}
#define set_reg(reg, val) __set_reg(reg, par->val, &oldpar->val)
and use
oldpar = fb_info->par;
set_reg(REG_XX1, reg_xx1);
set_reg(REG_XX2, reg_xx2);
set_reg(REG_XX3, reg_xx3);
set_reg(REG_XX4, reg_xx4);
This is also useful for accel engine setup for accelerated rectcopy/rectfill.
> please read the text in vfb.c after appling the patch. It represents the
> ideas where fbcon is heading in terms of future API. Please take advantage
> of the var and fix fields inside fb_info. This patch also adds a fbcmap
> field to fb_info.
OK.
Gr{oetje,eeting}s,
--
Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} -- geert@linux-m68k.org
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
-
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/