Re: [linux-fbdev] New api again

[James S. <jsi...@su...>]

> > /*
> > *  Set a single color register. The values supplied have a 16 bit
> > *  magnitude. Return != 0 for invalid regno. This routine assumes
> > *  your graphics hardware is packed pixel based (most are :-).
> > *  Return != 0 for invalid regno.
> > */
> > static int xxxfb_setcolreg(unsigned regno, unsigned red, unsigned green,
> > unsigned blue, unsigned transp,
> > const struct fb_info *info)
> 
> Could there be a multiple color version as well?  For 2.4, I have my own
> fb_set_cmap to do that since a cmap access requires a synchronization with
> vsync for the first one on my machine, and I don't want to do the
> synchronization for every cmap change.
> 
> Want to do:
> - vsync
> - multiple cmap change
> rather than:
> - vsync
> - a cmap change
> - vsync
> - a cmap change
> - ....
>
> If there is a way to override fb_set_cmap (or a new api's equilvalent)
> calling setcolreg, that would be okay, too.

Hum. I would prefere a setcolreg solution more. fb_set_cmap in fbcmap.c is
more for grabbing the info from userland then setting the hardware.

> [...]
> > info.pseudo_palette = xxxfb_pseudo_palette;
> 
> How is this psuedo_palette used for new api?

It is actually for the higher up fbcon layer. Traditional VTs only had
psuedocolor modes so we have to fake it for video modes that don't have 
color maps. We can do things like:

bgx = ((u16 *)p->dispsw_data)[attr_bgcol_ec(p, conp)];

Personally I hate it and wish their was another way around this.