linux-fbdev-devel — linux-fbdev mailing list for project developers

[Linux-fbdev-devel] Fb_find_mode from modedb.c doesn't show printk-statements

[Otto W. <ott...@bl...>]

I've inserted a printk-statement (with "KERN_INFO") right at the
beginning of fb_find_mode (kernel 2.4.5, i386) but it isn't shown during
startup or in /var/log/syslog. What's wrong? I've also inserted a printk
right before and after calling fb_find_mode in aty128fb.c and these are shown.

Here is my /var/log/syslog
--------------------------------------
[...]
kernel: aty128fb: Parameter NOACCEL set to 1
kernel: aty128fb: Parameter FONT set to VGA16x8
kernel: aty128fb: Parameter MODE set to 800x600@72
kernel: aty128fb: Parameter NOMTRR set to 1
kernel: aty128fb: Rage128 BIOS located at segment C00C0000
kernel: aty128fb: Rage128 Pro PF (AGP) [chip rev 0x1]
kernel: 32M 128-bit SDR SGRAM (1:1)
kernel: aty128fb: TEST0: Find mode = 800x600@72
kernel: __fb_try_mode: Trying mode noname 640x480-8@60
kernel: aty128fb: Test1: Mode found
kernel: Console: switching to colour frame buffer device 80x30
kernel: fb0: ATY Rage128 frame buffer device on PCI
[...]
--------------------------------------
All I get is the line with "__fb_try_mode" with the wrong mode.

Besides why is modedb.c not modularizable or where is the appropriate
switch in make menuconfig?

O. Wyss

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

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

On Fri, 22 Jun 2001, James Simmons wrote:
> > > BTW I'd love to work on adding Rage128 and Radeon support to the new atyfb.
> > 
> > Please coordinate with Ani, he already started to work on that.
> 
> Is this such a wise idea? I know the ati 128 can be run in DMA mode but
> can a MACH 64 card also be done in DMA? Once 2.5.X comes out and the
> patches I have go in we can migrate to using DMA/irq. The rage 128 works
> far far better in CCE mode plus the accel engine is far more stable. You
> can tell the ATI engineers focus on DMA performance and stability over
> mmio.

At least the 3D RAGE II+ and 3D RAGE PRO have support for busmastering DMA,
including queueing acceleration commands in a buffer in RAM.

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

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

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

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

> > BTW I'd love to work on adding Rage128 and Radeon support to the new atyfb.
> 
> Please coordinate with Ani, he already started to work on that.

Is this such a wise idea? I know the ati 128 can be run in DMA mode but
can a MACH 64 card also be done in DMA? Once 2.5.X comes out and the
patches I have go in we can migrate to using DMA/irq. The rage 128 works
far far better in CCE mode plus the accel engine is far more stable. You
can tell the ATI engineers focus on DMA performance and stability over
mmio.

[Linux-fbdev-devel] Re: [PATCH] fbgen & multiple RGBA

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

> the attached patch fix a problem with fbgen when changing the
> RGBA components but not the depth ; fbgen would not change
> the colormap in this case, where it should.

It would be much easier to use a memcmp.

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

[Petr V. <VAN...@vc...>]

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...
                                                    

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

[Michel <mic...@ii...>]

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

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 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

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

[Petr V. <VAN...@vc...>]

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...
                                                    

[Linux-fbdev-devel] [PATCH] fbgen & multiple RGBA

[Romain D. <dol...@cl...>]

Hello,

the attached patch fix a problem with fbgen when changing the
RGBA components but not the depth ; fbgen would not change
the colormap in this case, where it should.

-- 
romain

Re: [Linux-fbdev-devel] XFbdev and frame buffer driver

[Michel <mic...@ii...>]

Ghozlane Toumi wrote:

> I have a slight problem whith Xfbdev on tom of my home brew driver :
> 
> If from X i switch back to a console driven by the driver, X dies horibly
> with a seg 11 .
> 
> When i kill X (ctr-alt-backspace) , the console doesn't clean itself, and
> the screen is a mix of the X display + the text on the console .
> 
> so my questions is : how switching back and forth betwen console
> and X (on the same fb driver) is handled, and does anyone has an
> idea of why X dies like that ?

I suggest looking at the ioctls it uses (xc/programs/Xserver/hw/kdrive/fbdev/)
and make sure your driver fully supports them.


-- 
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

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

[Michel <mic...@ii...>]

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

[Linux-fbdev-devel] XFbdev and frame buffer driver

[Ghozlane T. <gt...@pr...>]

Hello all ...

I have a slight problem whith Xfbdev on tom of my home brew driver :

If from X i switch back to a console driven by the driver, X dies horibly
with a seg 11 .

When i kill X (ctr-alt-backspace) , the console doesn't clean itself, and
the screen is a mix of the X display + the text on the console .


so my questions is : how switching back and forth betwen console
and X (on the same fb driver) is handled, and does anyone has an
idea of why X dies like that ?

thanks in avance ..

ghoz

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

[Petr V. <VAN...@vc...>]

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...
                                                    
                                                

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

[Michel <mic...@ii...>]

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

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

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

On Fri, 22 Jun 2001, Michel D=E4nzer wrote:
> Geert Uytterhoeven wrote:
> > On Fri, 22 Jun 2001, Michel D=E4nzer wrote:
> > > While this now works perfectly in X for both depth 15 and 16 as wel=
l as in
> > > console for fbset -depth 16 -rgba 5,5,5,0 , some colors are wrong f=
or
> > > fbset -depth 16 -rgba 5,6,5,0 . It's not clear to me whether the pa=
lette
> > > for
> >=20
> > Funny, I have similar problems with atyfb and 565 (didn't manage to g=
et X
> > working yet, since I still use 3.3.6 which seems to pass invalid para=
meters
> > when being `strict' in the color bitfield checking).
>=20
> I know, Michael Schmitz forwarded your patch to me, it helped me a lot,
> thanks.
>=20
> > > 565 should have 32 or 64 entries.
> >=20
> > 64 of course. But red and blue should fill the first 32 entries only.
>=20
> Okay, but why do you allocate a cmap with only 32 entries then? Do you
> extrapolate the missing green entries in this line?
>=20
>            green =3D 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 corr=
ect
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);

> be greater than 255, so what's the 0xff for?

I wanted to be sure, you never know...

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

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

[Michel <mic...@ii...>]

Romain Dolbeau wrote:
> 
> 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 565 should have 32 or 64 entries.
> 
> Does the problem you mention occur when you switch directly
> from RGBA 5551 to RGBA 5650 ? Does it also happen if you
> switch to 32bpp RGB8888 or 8bpp CI8 in-between ?

It's the same no matter what I change to 5650 from.

> I have a similar problem with pm3fb, if I change the RGBA
> component but not the depth, colors are wrong, but changing
> depth and back fix the problem. Maybe it's the same bug and
> not directly related to the driver ?

Switching between 5550 and 5650, the colors are always right with the former
and wrong with the latter for me.


-- 
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

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

[Michel <mic...@ii...>]

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
be greater than 255, so what's the 0xff for?


> > BTW I'd love to work on adding Rage128 and Radeon support to the new
> > atyfb.
> 
> Please coordinate with Ani, he already started to work on that.

Seems he and I are doing the same things a lot recently. :)


-- 
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

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

[Romain D. <do...@ir...>]

Geert Uytterhoeven wrote:

> Is this in the console?

Yes.

> If yes, the color map has to be updated when the depth is changed.
> Probably fbgen (or pm3fb) tests for the bpp only.

Yes, fbgen_set_var doesn't check for the RGBA component,
only bits_per_pixel, before changing cmap.

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

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

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

On Fri, 22 Jun 2001, Romain Dolbeau wrote:
> Michel D=E4nzer wrote:
> > The attached patch significantly enhances the 16 bit handling of aty1=
28fb.
> > I've achieved this mainly by consequently distinguishing between 'dep=
th' and
> > 'bpp'. I've used these terms for the same meanings as in XFree86 4.x;=
 please
> > let me know if you prefer other terms.
> >
> > 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 pale=
tte for
> > 565 should have 32 or 64 entries.
>=20
> Does the problem you mention occur when you switch directly
> from RGBA 5551 to RGBA 5650 ? Does it also happen if you
> switch to 32bpp RGB8888 or 8bpp CI8 in-between ?
>=20
> I have a similar problem with pm3fb, if I change the RGBA
> component but not the depth, colors are wrong, but changing
> depth and back fix the problem. Maybe it's the same bug and
> not directly related to the driver ?

Is this in the console?

If yes, the color map has to be updated when the depth is changed. Probab=
ly
fbgen (or pm3fb) tests for the bpp only.

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

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

[Romain D. <do...@ir...>]

Michel D=E4nzer wrote:
>=20
> The attached patch significantly enhances the 16 bit handling of aty128=
fb.
> I've achieved this mainly by consequently distinguishing between 'depth=
' and
> 'bpp'. I've used these terms for the same meanings as in XFree86 4.x; p=
lease
> let me know if you prefer other terms.
>
> 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 palett=
e for
> 565 should have 32 or 64 entries.

Hello,

Does the problem you mention occur when you switch directly
from RGBA 5551 to RGBA 5650 ? Does it also happen if you
switch to 32bpp RGB8888 or 8bpp CI8 in-between ?

I have a similar problem with pm3fb, if I change the RGBA
component but not the depth, colors are wrong, but changing
depth and back fix the problem. Maybe it's the same bug and
not directly related to the driver ?

--=20
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

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

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

On Fri, 22 Jun 2001, Michel D=E4nzer 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 palett=
e 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 paramete=
rs
when being `strict' in the color bitfield checking).

> 565 should have 32 or 64 entries.

64 of course. But red and blue should fill the first 32 entries only.

> BTW I'd love to work on adding Rage128 and Radeon support to the new at=
yfb.

Please coordinate with Ani, he already started to work on that.

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

Re: [Linux-fbdev-devel] Interface for detecting HSYNC / VSYNC

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

> I've got a video controller that can generate an interrupt when it's not
> refreshing the screen, so as to give the applications a chance to redraw
> without flicker.  What's the interface for this sort of thing.  I see
> several #defines for FB_SYNC_*, but I'm not sure how to use them.   I would
> think, send the process a signal, but that may be to slow.
> 
> Any good solutions?  What's current status quo?

   Really none. Their is a ioctl call but it is more report where the beam 
is. So you have to have the program basicly keep calling the ioctl
until something happens. Not very efficient.  
   What you could do is implement poll so you could do a select on the
fbdev file descriptor. 
   Note: You have to be careful with the console spinlock which disables
IRQs. While the console spinlock is held the interrupt will never trigger.
The HSYNC and VSYNC are for setting the card according to the monitors
abilities. 

Re: [Linux-fbdev-devel] Panning

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

> When indicating xpanstep and ypanstep in fix_screeninfo, should I indicate
> the panning in pixels or bytes?  That is, if I have a 1 bit display that
> packs 8 bits to each byte, and I can tell it to change its horizontal on a
> 1 byte (8 bit, 8 pixel) granularity, should I report 1 or 8 in xpanstep?

Report a 8.

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

[Michel <mic...@ii...>]

The attached patch significantly enhances the 16 bit handling of aty128fb.
I've achieved this mainly by consequently distinguishing between 'depth' and
'bpp'. I've used these terms for the same meanings as in XFree86 4.x; please
let me know if you prefer other terms.

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
565 should have 32 or 64 entries.


The patch is against 2.4.5-pre3 from Benjamin Herrenschmidt's tree so the
offsets are probably off for Linus' tree.


BTW I'd love to work on adding Rage128 and Radeon support to the new atyfb.


PS: Ah yes, the patch also fixes panning. :)

-- 
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member