Re: [Linux-fbdev-devel] fb_imageblit()

[Antonino D. <ad...@po...>]

On Thu, 2003-01-09 at 17:50, Geert Uytterhoeven wrote:
> On 9 Jan 2003, Antonino Daplas wrote:
> > On Wed, 2003-01-08 at 23:15, Geert Uytterhoeven wrote:
> > > > c. Read color information from pseudopalette if directcolor/truecolor. 
> > > 
> > > Hoever, pseudopalette has entries for the first 16 colors only!
> > > Hence you are limited to the 16 color for directcolor/truecolor modes.
> > 
> > That's why there's an fb_set_logo_directpalette(), for directcolor
> > visuals >= 24bpp, and fb_set_logo_truepalette(), for truecolor, in
> > fb_set_logo().  Basically, it temporarily replaces info->pseudo_palette
> > with one that has 256 entries to match linux_logo.  Logo drawing, using
> > cfb_imageblit() has always worked for me in directcolor and truecolor
> > modes.
> 
> I see a small inconsistency here, which may cause problems with some exotic
> hardware: info->pseudo_palette is always initialized by the fbdev driver itself
> (which knows the hardware), except for logo drawing, where it's done by the
> generic code in fbmem.
> 
> On virtually all hardware that will work fine. But on some hardware the exact
> pixel format cannot be represented by the {red,green,blue,transp} bitfields in
> fb_var_screeninfo.
> 
> E.g. the Amiga CyberVision64 card has a S3Trio64. Since Amigas are little
> endian and PCI is big endian, they swapped the data bus to simplify 256-color
> modes. However, this also means that 16-bit pixel values have to be swapped. So
> in depth 15, the pixel format is not ARRRRRGGGGGBBBBB, but GGGBBBBBARRRRRGG.
> This can be handled fine in cyberfb by setting up a byteswapped pseudo palette,
> but the fb_set_logo_{direct,true}palette() don't know about this. And of course
> user space doesn't know about this neither.
> 

This will be a problem only for DirectColor at >= 24 bpp.  At bpp's less
than that, linux_logo_16 will be used.

Another possible solution (in case it supports 24bpp) is to have 2
pseudo_palettes, one which is 16 entries long and public, and another
256-entries long and private.  Then if image.depth is < 24, it's safe to
use cfb_imageblit. Otherwise, it has to use it's own imageblit, one that
will use the private pseudo_palette.  The driver will have the
opportunity to build this because fb_set_cmap() is called for
directcolor modes >= 24bpp, and pseudocolor == 8bpp.

Hopefully, exotics such as this will not export their visuals as
truecolor or static pseudocolor because fb_set_cmap() will not be
called. Otherwise, we'll just make it mandatory to call fb_set_cmap()
for all visual modes requiring linux_logo.
  
> One possible solution is to extend the pseudo palette to 256+1 entries if the
> depth is at least 8. To save memory, we can still use a 16+1 entry pseudo
> palette if depth < 8, but then we have to move the cursor inversion value from
> index 16 to index -1.
> 

I believe the cursor inversion value is unused anymore(?), since
fbcon_revc is gone. It has been replaced by the new cursor API which
allows the driver more intimate handling of the cursor.

Tony