From: Petr V. <VAN...@vc...> - 2001-06-22 14:53:29
|
On 22 Jun 01 at 15:06, Michel D=E4nzer wrote: > Petr Vandrovec wrote: > > > > On 22 Jun 01 at 13:11, Geert Uytterhoeven wrote: > > > > > > 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, blu= e); > > > > I do not see rest of code, but does your code correctly set > > zero register? Is not green field overwritten by its old value? > > If the order is wrong, it can be changed. Order is not wrong. Idea is wrong... You must do: if (regno) { <your old code> } else { aty_st_dac(0, red, green, blue); } as 'old' code sets either green, or red+blue wrong. > > Can you try 'echo "^[]P0FFFFFF"' and switch to some other console and = back? > > If you still see white background, OK. If you see something else (such= as > > magentha background)... > > That doesn't do anything but print the string for me? ^[ means escape character - with bash it is Ctrl+V and ESC > > BTW, I think that you should use truecolor instead. It is much easier, > > and truecolor can cooperate with fbtv, while directcolor has bad troub= les > > due to strange system which truecolor uses for painting characters. > > I assume you mean directcolor. I don't think it's worth sacrifying direc= tcolor No (if truecolor is one which does not use palette) > just because it's more complicated. XFree86 shows how to use it for gamm= a > correction, fbcon shows how to use it to simulate pseudocolor. You can't= have > either with truecolor. Yes, you cannot. But on other side you can have fbcon text together with picture, and this outweights all these problems - except gamma. And for gamma we should have another API anyway, as there are really two completely different things done through set palette API, as I complained looong ago. 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 map (and console color->pixel color is hardwired in code for pseudocolor (where I can live with it) and for truecolor (where I cannot live with it, as in current scheme you can have only 16 color values for R,B, and 16 or 48 for G (in 555 resp. 565), if you want picture with text, and you do not want to paint text yourself). With two tables instead of one we could implement everything we need, and we could support per-fb gamma correction together with per-vt colormap. Currently there is no way to get per-fb gamma... > > Been there, done that, and hardwired palette registers to 1:1 in matro= xfb... > > How? By programming them "for (i=3D0; i<256; i++) palette[i] =3D (RGB){i,i,i};"= ;-) Best regards, Petr Vandrovec van...@vc... |