Menu
▾
▴
linux-fbdev-devel
|
From: Petr V. <VAN...@vc...> - 2001-06-22 12:27:12
|
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, blue);
I do not see rest of code, but does your code correctly set
zero register? Is not green field overwritten by its old value?
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)...
BTW, I think that you should use truecolor instead. It is much easier,
and truecolor can cooperate with fbtv, while directcolor has bad troubles
due to strange system which truecolor uses for painting characters.
Been there, done that, and hardwired palette registers to 1:1 in
matroxfb...
Best regards,
Petr Vandrovec
van...@vc...
|
|
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...
|
|
From: Geert U. <ge...@li...> - 2001-06-22 15:04:48
|
On Fri, 22 Jun 2001, Petr Vandrovec wrote:
> 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, =
blue);
> > >=20
> > > I do not see rest of code, but does your code correctly set
> > > zero register? Is not green field overwritten by its old value?
> >=20
> > If the order is wrong, it can be changed.
>=20
> Order is not wrong. Idea is wrong... You must do:
>=20
> if (regno) {
> <your old code>
> } else {
> aty_st_dac(0, red, green, blue);
> }=20
>=20
> as 'old' code sets either green, or red+blue wrong.
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.
> 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+regn=
o<<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 fb=
dev
behavior here.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m6=
8k.org
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
|
|
From: Michel <mic...@ii...> - 2001-06-22 15:43:33
|
Petr Vandrovec wrote:
>
> On 22 Jun 01 at 15:06, Michel Dänzer 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,
> > > > blue);
> > >
> > > 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.
Interesting, but white stays white with your example. :)
--
Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast \ XFree86 and DRI project member
|
|
From: Petr V. <VAN...@vc...> - 2001-06-22 16:12:08
|
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
you program same register twice...
> > 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?
Best regards,
Petr Vandrovec
van...@vc...
|
|
From: Geert U. <ge...@li...> - 2001-06-22 17:01:17
|
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
|
|
From: Michel <mic...@ii...> - 2001-06-22 13:06:24
|
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, blue); > > 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. > 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? > BTW, I think that you should use truecolor instead. It is much easier, > and truecolor can cooperate with fbtv, while directcolor has bad troubles > due to strange system which truecolor uses for painting characters. I assume you mean directcolor. I don't think it's worth sacrifying directcolor just because it's more complicated. XFree86 shows how to use it for gamma correction, fbcon shows how to use it to simulate pseudocolor. You can't have either with truecolor. > Been there, done that, and hardwired palette registers to 1:1 in matroxfb... How? PS: Everything works now, cooking up a new patch. :) -- Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \ XFree86 and DRI project member |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X