Re: [linux-fbdev] New api again

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

> On 1/17/01 2:33 AM, Geert Uytterhoeven wrote:
> 
> > On Tue, 16 Jan 2001, Takashi Oe wrote:
> >> 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.
> >> 
> [...]
> > Can't you buffer the xxxfb_setcolreg() calls and execute them in the vsync
> > interrupt handler? Busy waiting until vsync is a bad idea.
> 
> Yes, the vsync irq handler is the way it's done currently for one fb.
> Howerver, there is another regrettably more popular fb with the same
> requirement without the vsync irq routed to cpu; that is, the busy waiting
> seems to be the only way....

Okay. This answered my previous question. It pretty much comes down to
choosing between xxxfb_setcolreg or xxxfb_set_cmap. Their are pros and
cons to having each:
                  
xxxfb_setcolreg  
PRO:         can change a individual register without having to monkey
             with the entire CLUT. 

CONS:        Hardware designs. Some hardware require vsync when changing
	     the color palette.

xxxfb_set_cmap
PRO:	     More flexiable with bizarre hardware. Also works nice with 
	     hardware that has more than one CLUT. In this case we can
	     cache a bunch of color maps and switch the index around. 	   
            	     
CONS:        Can't change a subset of teh CLUT table easily.