Re: [Linux-fbdev-devel] [PATCH] aty128fb 15/16 bit cleanup

[Geert U. <ge...@li...>]

On Fri, 22 Jun 2001, Petr Vandrovec wrote:
> On 22 Jun 01 at 17:01, Geert Uytterhoeven wrote:
> > > > > I do not see rest of code, but does your code correctly set
> > > > > zero register? Is not green field overwritten by its old value?
> > 
> > Perhaps I'm in a bad mood, but I still fail to see what's wrong with the above
> > code...
> > 
> > Note that palette[regno] is set before aty_st_dac() is called.
> 
> Then nothing. Sorry, as I said - I did not look at code. Besides that

OK.

> you program same register twice...

Not the same register, they differ by the shift value.

> > > We have console color <0-15>, pixel color <0-(1<<bpp-1)> and displayed
> > > color <rgb 0-65535,0-65535,0-65535>. set palette API sets
> > > pixel color -> displayed color value for pseudocolor and direct color
> > > (and for directcolor in really strange manner as shown by regno<<3+regno<<2
> > > troubles), while for truecolor it sets console color -> pixel color
> > 
> > The `regno<<3+regno<<2' stuff is there because of a hardware feature: in RGB565
> > mode, the red and blue entries are spaced apart 8 entries (256/32), while the
> > green entries are spaced apart 4 entries (256/64). So there's no weird fbdev
> > behavior here.
> 
> It is. set_palette sets completely different things for each visual type.
> And entries 0-15 are stored per-VT by console code (and can be changed
> through ESC sequence), while entries 16..x (where x = one of 31,63,255,...) 
> are not stored anywhere... If this is not strange API, then what is?

The console code takes care of the first 16 colors only. Anything else should
be done by the application.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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