Re: [Linux-fbdev-devel] vga256fb

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

On 14 May 01 at 11:31, antirez wrote:
> On Mon, May 14, 2001 at 08:33:00AM +0200, Geert Uytterhoeven wrote:
> > On Sat, 12 May 2001, antirez wrote:
> > > you can download the quite useless vga256fb device driver
> > > at http://www.kyuzz.org/antirez/vga256fb.html.
> > > 
> > > I used it for an embedded project, than I added the "tweaked"
> > > VGA modes for fun, with a software hack.
> > > While useless, to run at 360x480 in 256 colors with a standard
> > > VGA card can be funny ;)
> > > 
> > > As you can guess, this driver will waste your CPU and RAM
> > > when in linear emulation mode.
> > 
> > Would it be useful to integrate vga16fb and vga256fb?
> 
> Yes, why to split in two drivers modes supported by the same
> hardware?

I have vga16fb patched to support 256 colors for eons. I believe that
James maintains patch currently, but if not I can extract it from my tree.
It does 16color VGA planes, 16color packed pixels (on some hardware),
256color VGA planes + packed pixels and native VGA textmode.

> I did vga256fb as a stand-alone driver since:
> 
> 1) It was a real-world work, the timeline was very short, and vga16 was
>    not trivial to modify for a 256 color mode.
> 2) vga16fb is a FB_TYPE_VGAPLANES, but vga256fb is a
>    FB_TYPE_PACKED_PIXELS driver.
> 3) vga256fb is "mode oriented", while vga16fb converts arbitrary
>    xres, yres values to hardware settings. I'm not sure it's possible
>    to do it for 256 colors tweaked modes.

My driver does 320x200 in FB_TYPE_PACKED_PIXELS, or 360x480 with
FB_TYPE_VGA_PLANES&FB_AUX_VGA_PLANES_CFB8...

> user select an unchained mode the first time. While the linear emulation
> task is stopped once you return to a linear mode, the memory will
> never be freed (it may be in use by another console, also vmalloc()/vfree()
> 360*480 bytes every time a user enter/leave a unchained mode seems bad).

Linear emulation cannot work for fbtv! Make sure that running fbtv on such
device will not overwrite innocent part of kernel ;-)
 
                                                Best regards,
                                                    Petr Vandrovec
                                                    van...@vc...