From: Michel <mic...@ii...> - 2001-06-22 11:38:00
|
Geert Uytterhoeven wrote: > > On Fri, 22 Jun 2001, Michel Dänzer wrote: > > Geert Uytterhoeven wrote: > > > On Fri, 22 Jun 2001, Michel Dänzer wrote: > > > > While this now works perfectly in X for both depth 15 and 16 as well as in > > > > console for fbset -depth 16 -rgba 5,5,5,0 , some colors are wrong for > > > > fbset -depth 16 -rgba 5,6,5,0 . It's not clear to me whether the palette > > > > for > > > > > > Funny, I have similar problems with atyfb and 565 (didn't manage to get X > > > working yet, since I still use 3.3.6 which seems to pass invalid parameters > > > when being `strict' in the color bitfield checking). > > > > I know, Michael Schmitz forwarded your patch to me, it helped me a lot, > > thanks. > > > > > > 565 should have 32 or 64 entries. > > > > > > 64 of course. But red and blue should fill the first 32 entries only. > > > > Okay, but why do you allocate a cmap with only 32 entries then? Do you > > extrapolate the missing green entries in this line? > > > > green = info->palette[(2*regno) & 0xff].green; > > ^^^^^^^^^^^^^^^^ > > I don't understand what this is supposed to do. As 0<regno<32, (2*regno) > > can't > > For palette index regno, red and blue are stored in a different DAC entry > than green. So when I store red and blue, I have to make sure I write the > correct green value there. That green value is palette[regno*2].green. > Follow the fall-through and merge the code: > > aty_st_dac(regno << 2, palette[regno/2].red, green, > palette[regno/2].blue); > aty_st_dac(regno << 3, red, palette[(2*regno) & 0xff].green, blue); Okay, I think I understand now. XFree86 actually sends 64 entries so that has to be dealt with. I'm going to use the 1 1/4 hours on the train for some more hacking... -- Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \ XFree86 and DRI project member |