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

Re: [Linux-fbdev-devel] how to support almost compatible bo

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

On 19 Jun 01 at 16:48, Ghozlane Toumi wrote:

> -strange things : I have a value, previously stored in one bitfield R1 [7:4]
> which is now dispatched in 3 bitfields :
> { R1[24],  R1[7:4],  R2[30] }  R2 being a "new" register added to the
> architecture.
> (the value was representing a number of 64 pixel wide tiles and to maintain
> compatibility, it now reprents the number of .. 32 pixels wide tiles ...)

Do you mean that value is now (MSB to LSB) R2[30] R1[24] R1[7:4], or is
it really R2[30] R1[7:4] R1[24] ?

Anyway, easiest thing is:

if (fbinfo.capable.tile_is_64) {
   r1 = (r1 & ~0x010000F0) | ((v & 0xF) << 4) | ((v & 0x10) << (24 - 4));
   r2 = (r2 & ~0x40000000) | (v & 0x20) << (30 - 5);
} else {
   if (v > 0xF) {
      printk(KERN_DEBUG "Stupid, tile > 16!");
   }
   r1 = (r1 & ~0x000000F0) | ((v & 0xF) << 4)
}

All drivers are full of such code.
                                            Petr Vandrovec
                                            van...@vc...
                                            

Re: [Linux-fbdev-devel] 2 pm3fb questions/problesm ...

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

On 19 Jun 01 at 16:48, Sven LUTHER wrote:
> 
> BTW, any idea about the 'initial garbage when using pm3fb' problem ?

And this is what? Do you mean that vgacon -> pm3fb switch during
bootup does not preserve contents of screen? Make sure that
on enter to register_framebuffer() pm3fb is in VGA mode, memory
is mapped at 0xB8000 and SEQ/GDC/CRTC are set for VGA text mode.
During register_framebuffer() vgacon reads VGA videoram, then
_set_var (I believe that implicitly through your console_switch) of 
your framebuffer is invoked, and screen is repainted using putcs...

So you should have some currcon variable in your fbinfo:

fbinfo.currcon = -1;
register_framebuffer(&fbinfo);
if (fbinfo.currcon == -1) {
   /* we are second head... */
   yourfb_set_var(.....);
}

and your fbinfo_select_console should do:

fbinfo.currcon = new_console;
yourfb_set_var(.....);

and all code which changes memory layout and enables/disables VGA emulation
should be executed only from inside yourfb_set_var and not before
call to register_framebuffer.
                                                Best regards,
                                                        Petr Vandrovec
                                                        van...@vc...
                                                        

[Linux-fbdev-devel] how to support almost compatible boards with one driver ?

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

Hi,

I'm seeking for an advice , related to code cleanness ...

My problem : i'm trying to support 2 "almost" compatible video boards.
the compatible part is ok, the "almost" one is a little bit annoying.

All the registers are the same, with some exeptions:

-increased bitfield size (R [4:0] is now R[6:0] for instance)
-strange things : I have a value, previously stored in one bitfield R1 [7:4]
which is now dispatched in 3 bitfields :
{ R1[24],  R1[7:4],  R2[30] }  R2 being a "new" register added to the
architecture.
(the value was representing a number of 64 pixel wide tiles and to maintain
compatibility, it now reprents the number of .. 32 pixels wide tiles ...)

I think I'm ok with the first type of 'improvment', but i don't really know
how to
cope cleanly with the 2nd type ...

any experiences /  ideas / advices ?

Thank you

ghoz

Re: [Linux-fbdev-devel] 2 pm3fb questions/problesm ...

[Sven L. <lu...@dp...>]

On Tue, Jun 19, 2001 at 04:38:02PM +0200, Geert Uytterhoeven wrote:
> On Tue, 19 Jun 2001, Sven LUTHER wrote:
> > On Tue, Jun 19, 2001 at 04:03:59PM +0200, Geert Uytterhoeven wrote:
> > > On Tue, 19 Jun 2001, Sven LUTHER wrote:
> > > > And the correct thing to do is ?
> > > 
> > > EXOR with 15 for pseudocolor
> > 
> > mmm, so in the accelerated case, doing a Invert logical op with the writemask
> > set to 0x0f0f0f0f (that is only inverting the lower 4 bits of each pixels)
> > should od the trick.
> > 
> > BTW, forgive me if i am being stupid, but why not doing a bitwise not ?
> 
> Because that would invert too many bits.

A ok, ...

BTW, any idea about the 'initial garbage when using pm3fb' problem ?

friendly,

Sven Luther

Re: [Linux-fbdev-devel] 2 pm3fb questions/problesm ...

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

Geert Uytterhoeven wrote:
> 
> On Tue, 19 Jun 2001, Sven LUTHER wrote:
> > BTW, forgive me if i am being stupid, but why not doing a bitwise not ?
> 
> Because that would invert too many bits.

I think Sven was thinking of a bitwise not with an hardware
mask set to 0x0F0F0F0F, which should have the same result,
and with the added benefit that there's no need to transfer
the second source of the XOR. So it's easier to do on the
permedia3 :-)

-- 
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] 2 pm3fb questions/problesm ...

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

On Tue, 19 Jun 2001, Sven LUTHER wrote:
> On Tue, Jun 19, 2001 at 04:03:59PM +0200, Geert Uytterhoeven wrote:
> > On Tue, 19 Jun 2001, Sven LUTHER wrote:
> > > And the correct thing to do is ?
> > 
> > EXOR with 15 for pseudocolor
> 
> mmm, so in the accelerated case, doing a Invert logical op with the writemask
> set to 0x0f0f0f0f (that is only inverting the lower 4 bits of each pixels)
> should od the trick.
> 
> BTW, forgive me if i am being stupid, but why not doing a bitwise not ?

Because that would invert too many bits.

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] 2 pm3fb questions/problesm ...

[Sven L. <lu...@dp...>]

On Tue, Jun 19, 2001 at 04:03:59PM +0200, Geert Uytterhoeven wrote:
> On Tue, 19 Jun 2001, Sven LUTHER wrote:
> > And the correct thing to do is ?
> 
> EXOR with 15 for pseudocolor

mmm, so in the accelerated case, doing a Invert logical op with the writemask
set to 0x0f0f0f0f (that is only inverting the lower 4 bits of each pixels)
should od the trick.

BTW, forgive me if i am being stupid, but why not doing a bitwise not ?

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] 2 pm3fb questions/problesm ...

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

On Tue, 19 Jun 2001, Sven LUTHER wrote:
> On Tue, Jun 19, 2001 at 03:55:28PM +0200, Geert Uytterhoeven wrote:
> > On Tue, 19 Jun 2001, Sven LUTHER wrote:
> > > On Tue, Jun 19, 2001 at 02:08:11PM +0000, Petr Vandrovec wrote:
> > > > for truecolor and 4bpp pseudocolor, 0x0f0f0f0f is correct for
> > > > 8bpp pseudocolor, 0xXX0f0f0f (*) is for 24/32bpp directcolor,
> > > > 0x3DEF3DEF for 15bpp, 0x79EF79EF for 16bpp, and you cannot
> > > > use RGB332 truecolor without information loss.
> > > 
> > > mmm, truecolor is when the the rgb value is written directly to the pixel ?
> > > and pseudo color is when you use a color index table.
> > > 
> > > What exactly is direct color ?
> > 
> > truecolor:
> > 
> >     red = (pixel & redmask) >> redshift
> >     green = (pixel & greenmask) >> greenshift
> >     blue = (pixel & bluemask) >> blueshift
> > 
> > pseudocolor:
> > 
> >     red = redtable[pixel]
> >     green = greentable[pixel]
> >     blue = bluetable[pixel]
> > 
> > directcolor:
> > 
> >     red = redtable[(pixel & redmask) >> redshift]
> >     green = greentable[(pixel & greenmask) >> greenshift]
> >     blue = bluetable[(pixel & bluemask) >> blueshift]
> > 
> > To make sure revc always does the correct thing, there should be a 17th entry
> > in the display->dispsw_data telling the invertion mask.
> 
> And the correct thing to do is ?

EXOR with 15 for pseudocolor
EXOR with -1 for truecolor
EXOR with (15 << redshift | 15 << greenshift | 15 << blueshift) for directcolor

The directcolor case assumes your driver loaded the console palette to the DAC.
Some fbdevs load a linear palette to the DAC so it behaves like truecolor. In
that case, EXOR with -1. That's the reason why we need the 17th entry: fbcon-*
cannot guess easily which mode is being used.

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] 2 pm3fb questions/problesm ...

[Sven L. <lu...@dp...>]

On Tue, Jun 19, 2001 at 03:55:28PM +0200, Geert Uytterhoeven wrote:
> On Tue, 19 Jun 2001, Sven LUTHER wrote:
> > On Tue, Jun 19, 2001 at 02:08:11PM +0000, Petr Vandrovec wrote:
> > > for truecolor and 4bpp pseudocolor, 0x0f0f0f0f is correct for
> > > 8bpp pseudocolor, 0xXX0f0f0f (*) is for 24/32bpp directcolor,
> > > 0x3DEF3DEF for 15bpp, 0x79EF79EF for 16bpp, and you cannot
> > > use RGB332 truecolor without information loss.
> > 
> > mmm, truecolor is when the the rgb value is written directly to the pixel ?
> > and pseudo color is when you use a color index table.
> > 
> > What exactly is direct color ?
> 
> truecolor:
> 
>     red = (pixel & redmask) >> redshift
>     green = (pixel & greenmask) >> greenshift
>     blue = (pixel & bluemask) >> blueshift
> 
> pseudocolor:
> 
>     red = redtable[pixel]
>     green = greentable[pixel]
>     blue = bluetable[pixel]
> 
> directcolor:
> 
>     red = redtable[(pixel & redmask) >> redshift]
>     green = greentable[(pixel & greenmask) >> greenshift]
>     blue = bluetable[(pixel & bluemask) >> blueshift]
> 
> To make sure revc always does the correct thing, there should be a 17th entry
> in the display->dispsw_data telling the invertion mask.

And the correct thing to do is ?

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] 2 pm3fb questions/problesm ...

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

On Tue, 19 Jun 2001, Sven LUTHER wrote:
> On Tue, Jun 19, 2001 at 02:08:11PM +0000, Petr Vandrovec wrote:
> > for truecolor and 4bpp pseudocolor, 0x0f0f0f0f is correct for
> > 8bpp pseudocolor, 0xXX0f0f0f (*) is for 24/32bpp directcolor,
> > 0x3DEF3DEF for 15bpp, 0x79EF79EF for 16bpp, and you cannot
> > use RGB332 truecolor without information loss.
> 
> mmm, truecolor is when the the rgb value is written directly to the pixel ?
> and pseudo color is when you use a color index table.
> 
> What exactly is direct color ?

truecolor:

    red = (pixel & redmask) >> redshift
    green = (pixel & greenmask) >> greenshift
    blue = (pixel & bluemask) >> blueshift

pseudocolor:

    red = redtable[pixel]
    green = greentable[pixel]
    blue = bluetable[pixel]

directcolor:

    red = redtable[(pixel & redmask) >> redshift]
    green = greentable[(pixel & greenmask) >> greenshift]
    blue = bluetable[(pixel & bluemask) >> blueshift]

To make sure revc always does the correct thing, there should be a 17th entry
in the display->dispsw_data telling the invertion mask.

This should be implemented in 2.5.

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] 2 pm3fb questions/problesm ...

[Sven L. <lu...@dp...>]

On Tue, Jun 19, 2001 at 02:08:11PM +0000, Petr Vandrovec wrote:
> On 19 Jun 01 at 13:41, Sven LUTHER wrote:
> > On Tue, Jun 19, 2001 at 01:34:43PM +0200, Romain Dolbeau wrote:
> > > Sven LUTHER wrote:
> > > pm2fb use non-accelerated fbcon-cfb8, and this one
> > > simply do pixels = (pixels ^ 0x0f0f0f0f).
> > > 
> > > So I guess it is the answer :-)
> > 
> > Ok, let's go for this, in wait for a response from the more knowledgeable
> > fbdev gurus ...
> 
> I do not know whether I'm more knowledgeable, but revc, together with
> other character based functions (putc/putcs/clear (and maybe clear_margin))
> have to support only 16 colors. And it is driver bussiness how it will
> perform console color -> value in framebuffer mapping. But it is convient,

mmm, ok, ...

> and couple of apps expects that for pseudocolor console color is directly
> stored in framebuffer, so only palette entries 0 .. 15 are used. But
> you can use entries 0, 17, 34, 51, 68, ... 238, 255 as well - although

you mean using index 0x00, 0x11, 0x22, ... instead of indexes 0, 1, 2, ...

> I'm sure that some fbdev apps will not agree with you.

Is there some reason to do such ? I suppose the fbcon layer will need to know
about this, how do you tell it about it ?

> If you decide to use standard way, then using 0xffffffff is correct

that is with a writemask, isn't it ?

> for truecolor and 4bpp pseudocolor, 0x0f0f0f0f is correct for
> 8bpp pseudocolor, 0xXX0f0f0f (*) is for 24/32bpp directcolor,
> 0x3DEF3DEF for 15bpp, 0x79EF79EF for 16bpp, and you cannot
> use RGB332 truecolor without information loss.

mmm, truecolor is when the the rgb value is written directly to the pixel ?
and pseudo color is when you use a color index table.

What exactly is direct color ?

pm3 has a bit that you can set, called directcolor, which distinguish between
CI8 (pseudocolor) and RGBxxx (truecolor ?) formats. 

Anyway, the problem only appears in depth 8, since i think that the accel
engine knows how to invert color in truecolor format.

But in CI8, i think it simply inverts the color index, or something such, so
you would have to map the inverted colors in color index 240 to 255. 

What will happen when an app grabs the framebuffer and plays with it in 256
colors ? will the color map be saved/restored, and in such a case will only
the 16 first entries be saved, or all the 256 ones ?

Anyway, thanks for the info, ...

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] 2 pm3fb questions/problesm ...

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

On 19 Jun 01 at 13:41, Sven LUTHER wrote:
> On Tue, Jun 19, 2001 at 01:34:43PM +0200, Romain Dolbeau wrote:
> > Sven LUTHER wrote:
> > pm2fb use non-accelerated fbcon-cfb8, and this one
> > simply do pixels = (pixels ^ 0x0f0f0f0f).
> > 
> > So I guess it is the answer :-)
> 
> Ok, let's go for this, in wait for a response from the more knowledgeable
> fbdev gurus ...

I do not know whether I'm more knowledgeable, but revc, together with
other character based functions (putc/putcs/clear (and maybe clear_margin))
have to support only 16 colors. And it is driver bussiness how it will
perform console color -> value in framebuffer mapping. But it is convient,
and couple of apps expects that for pseudocolor console color is directly
stored in framebuffer, so only palette entries 0 .. 15 are used. But
you can use entries 0, 17, 34, 51, 68, ... 238, 255 as well - although
I'm sure that some fbdev apps will not agree with you.
If you decide to use standard way, then using 0xffffffff is correct
for truecolor and 4bpp pseudocolor, 0x0f0f0f0f is correct for
8bpp pseudocolor, 0xXX0f0f0f (*) is for 24/32bpp directcolor,
0x3DEF3DEF for 15bpp, 0x79EF79EF for 16bpp, and you cannot
use RGB332 truecolor without information loss.
                                                    Petr
                                                    
(*) it is (15 << red.shift) | (15 << green.shift) | (15 << blue.shift)

Re: [Linux-fbdev-devel] 2 pm3fb questions/problesm ...

[Sven L. <lu...@dp...>]

On Tue, Jun 19, 2001 at 01:34:43PM +0200, Romain Dolbeau wrote:
> Sven LUTHER wrote:
> 
> > 2) use the above mentioned fix, and have color #0 inverted to color #15
> > 
> > What does other card do ? What did pm2fb do ?
> 
> easy answer, I should have looked before:
> 
> pm2fb use non-accelerated fbcon-cfb8, and this one
> simply do pixels = (pixels ^ 0x0f0f0f0f).
> 
> So I guess it is the answer :-)

Ok, let's go for this, in wait for a response from the more knowledgeable
fbdev gurus ...


Friendly,

Sven Luther

Re: [Linux-fbdev-devel] 2 pm3fb questions/problesm ...

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

Sven LUTHER wrote:

> 2) use the above mentioned fix, and have color #0 inverted to color #15
> 
> What does other card do ? What did pm2fb do ?

easy answer, I should have looked before:

pm2fb use non-accelerated fbcon-cfb8, and this one
simply do pixels = (pixels ^ 0x0f0f0f0f).

So I guess it is the answer :-)

-- 
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] 2 pm3fb questions/problesm ...

[Sven L. <lu...@dp...>]

On Tue, Jun 19, 2001 at 01:25:08PM +0200, Romain Dolbeau wrote:
> Sven LUTHER wrote:
> 
> > Mmm, romain, now that i think of it, you could maybe try setting the
> > FBHardwareWriteMask to only affect the lower 16 bit, this would be 0x0f0f0f0f
> > i think. Could you try this ?
> 
> That would indeed invert color #0 to color #15, but is it supposed to be
> the behavior of _revc ? isn't the inverted #0 another, different color
> not necessarily defined in the first 16 colors ?

Don't know, that's why i asked on linux-fbdev, we have to wait for an answer
there before doing anything about it.

But from what i see, there are only so much solutions to this :

1) use RGB 332 instead of CI8 :(((

2) use the above mentioned fix, and have color #0 inverted to color #15

3) put some inverted colors somewhere else.

4) use hardware cursor

5) don't use accels to do the cursor blinking in depth 8. mmm, this solved
nothing.

But the writemask solution is a ncie 2 register writes fix, if it works (you
have to restore the previous write_mask when you are done, i think, unless you
always stay in 16 colors only).

What does other card do ? What did pm2fb do ?

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] 2 pm3fb questions/problesm ...

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

Sven LUTHER wrote:

> Mmm, romain, now that i think of it, you could maybe try setting the
> FBHardwareWriteMask to only affect the lower 16 bit, this would be 0x0f0f0f0f
> i think. Could you try this ?

That would indeed invert color #0 to color #15, but is it supposed to be
the behavior of _revc ? isn't the inverted #0 another, different color
not necessarily defined in the first 16 colors ?

TIA

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

[Linux-fbdev-devel] 2 pm3fb questions/problesm ...

[Sven L. <lu...@dp...>]

Hello, ...

I have yesterday tested pm3fbs latest incarnation, and have some questions
resulting from 2 problems there still are with it.

1) The Console cursor is working fine in depth 15, 16, 32. The blinking cursor
is using the revc, which uses a destination inverting blit. But the depth 8
currsor is not working correctly. It shows the right thing when the cursor is
blinked away, but when it should be there everything is black.

Now, the only difference is that depth 15, 16, 32 (well anything beside 8) is
in directcolor, while depth 8 is in CI8 (color index, pseudocolor in fbdev
speach). RGB332 could be used to solve this, but somehow i don't think this is
the right solution.

What i guess happens is that when inverting a pseudocolor framebuffer trough
the accel engine, the former color n get's inverted to !n or something such.

To solve this, one could simply write the inverted values of colors index 0 to
15 to index 255 to 250. This should work ok for the 16 bit color console, but
i guess there are some apps that use the full 256 colors, isn't it ?

Mmm, romain, now that i think of it, you could maybe try setting the
FBHardwareWriteMask to only affect the lower 16 bit, this would be 0x0f0f0f0f
i think. Could you try this ?

But again, altough this solves the 16 color useage, it will not work if you
use all 256 colors. And in this case, will the revc function be used ? I
simply don't know enough about the whle fbdev scheme to say more here, and
thus i ask for advice.

2) Juste after the vgacon -> fbcon switch there is some garbage on the screen
that get later scrolled up and disappears (though it remains beside the
pengouin logo). This garbage is alternated black and green columns, with some
chars in the green columns, which seems to be follow the ascii code, so i
guess this may be the font map or something such of the vga text console.

Now romain (which don't experience this, since he has powermac) did a cleaning
of the whole framebuffer memory at pm3fb initialisation time. No this resulted
in a clearing of the screen before the switch, but the garbage still stayed
there after the switch.

So, where is the right place to do this cleaning, and where do you think this
garbage could come from ? Is it a problem that needs to be solved by pm3fb, or
a more generic fbdev/fbcon stuff ? Ideally i think fbcon should clear the
framebuffer memory before using it.

That said, i am not sure about the origin of the stuff, why should it appear,
even if we did clean the framebuffer at initialisation time ? does vgacon put
it there before being removed ? Or is it the fbcon font map that get's
misplaced, or somethign such ?

3) Also in the same vein, what happens when we load/unload pm3fb as a module.
Especially, if we manage to revert to vgacon and it's text mode ? Will vgacon
restore the fonts and other stuff it needs, or should fbdev save and the
nrestore the fonts and stuff, as X does.

Hope this was not too long ...

Friendly,

Sven Luther

[Linux-fbdev-devel] Re: sis630 - help needed debugging in the kernel

[Paul M. <le...@Ch...>]

On Mon, Jun 18, 2001 at 02:58:17PM -0700, James Simmons wrote:
> > Yep, in fbmem.c the name entry is "sisfb" as opposed to just "sis". 
> 
> Agh!!! That needs to be fixed. 
> 
I've already fixed it in ruby..

Regards,

-- 
Paul Mundt <le...@ch...>

[Linux-fbdev-devel] Re: sis630 - help needed debugging in the kernel

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

> > Is there another way to tell the fb driver what mode to use??
> > 
> Yep, in fbmem.c the name entry is "sisfb" as opposed to just "sis". 

Agh!!! That needs to be fixed. 

> Also, the
> driver requires that the mode is passed video a "mode:" argument as is
> outlined in the sisfb_setup(). Take a look at drivers/video/sis/sis_main.h,
> specifically sisbios_mode[] for a list of supported modes.

Broken. It should be using modedb. When I get the time I will send a fix.

[Linux-fbdev-devel] new wrapper

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

Sorry I have been quite. I hope tonight to have a the wrapper for 2.4.X
for the new api. I still have a few bugs to work out. No docs just yet.
Once I done with the code I will start working on the docs. I just
finished with the new secondary mips tree. It is sort of like a alan cox's 
tree for mips. I will be posting about this later.

[Linux-fbdev-devel] Re: sis630 - help needed debugging in the kernel

[René R. <ren...@gm...>]

On Mon, 18 Jun 2001 12:28:00 -0700
Paul Mundt <le...@Ch...> wrote:

[...]

> Yep, in fbmem.c the name entry is "sisfb" as opposed to just "sis". Also, the
> driver requires that the mode is passed video a "mode:" argument as is
> outlined in the sisfb_setup(). Take a look at drivers/video/sis/sis_main.h,
> specifically sisbios_mode[] for a list of supported modes.
> 
> Something like:
> 
> video=sisfb:mode:640x480x32
> 
> should do the job.

It crashed, too.

Full boot-up messages:

Kernel command line: root=/dev/discs/disc0/part2 video=sisfb:mode:640x480x32 console=ttyS0,9600 console=tty0  mem=131008K
Initializing CPU#0
Detected 631.427 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1258.29 BogoMIPS
Memory: 126484k/131008k available (1159k kernel code, 4136k reserved, 325k data, 204k init, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Celeron (Coppermine) stepping 03
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rg...@at...)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfda38, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router SIS [1039/0008] at 00:01.0
PCI: Found IRQ 10 for device 00:03.0
PCI: The same IRQ used for device 00:01.4
PCI: The same IRQ used for device 00:01.6
  got res[10000000:10000fff] for resource 0 of O2 Micro, Inc. OZ6812 Cardbus Controller
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
PnP: PNP BIOS installation structure at 0xc00f70b0
PnP: PNP BIOS version 1.0, entry at f0000:5f34, dseg at f0000
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd v1.8
VFS: Diskquotas version dquot_6.5.0 initialized
devfs: v0.102 (20000622) Richard Gooch (rg...@at...)
devfs: boot_options: 0x0
sisfb: framebuffer at 0xe0000000, mapped to 0xc8800000, size 65536k
sisfb: MMIO at 0xefce0000, mapped to 0xcc801000, size 128k
sisfb: encountered LCD
sisfb: fall back to 1024x768
sisfb: mode is 640x480x32, linelength=2560
sisfb: before sisfb_pre_setmod
sisfb: before SISSetMode
sisfb: before sisfb_post_setmode
sisfb: before sisfb_crtc_to_var
sisfb: before sisfb_set_disp
sisfb: before sisfb_heap_init
sisfb: before vc_resize_con
sisfb: before register_framebuffer
Unable to handle kernel paging request at virtual address cc800600
 printing eip:
c01ba5c0
*pde = 07f82067
*pte = 00000000
Oops: 0002
CPU:    0
EIP:    0010:[<c01ba5c0>]
EFLAGS: 00010246
eax: 00000000   ebx: 00000000   ecx: cc800600   edx: c02dc400
esi: 00000000   edi: c026d527   ebp: ffffffff   esp: c123de58
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 1, stackpage=c123d000)
Stack: c02c23e0 c02dc4c0 000006e4 00000000 00000a00 00000008 cc7fc000 c01ac77c 
       c1221000 c02dc4c0 c123f344 00000001 00000666 00000000 c123f342 c123f344 
       00000001 000006e4 c018150c c1221000 c123f342 00000001 000006e4 00000000 
Call Trace: [<cc7fc000>] [<c01ac77c>] [<c018150c>] [<c0181584>] [<c01adede>] 
   [<c0181f04>] [<c01856f9>] [<c01aaeb9>] [<c0105013>] [<c010542c>] 

Code: 89 01 88 d0 c0 e8 06 83 e0 01 f7 d8 21 d8 31 f0 89 41 04 88 
 <0>Kernel panic: Attempted to kill init!

ksymoops output:

ksymoops 2.3.7 on i686 2.4.4-ac5.  Options used
     -V (specified)
     -K (specified)
     -L (specified)
     -O (specified)
     -m /mnt/net/portable/usr/src/linux/System.map (specified)

Unable to handle kernel paging request at virtual address cc800180
c01b8f61
*pde = 0af2d067
Oops: 0002
CPU:    0
EIP:    0010:[<c01b8f61>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: 0f0f0f0f   ebx: c026e51c   ecx: 00000003   edx: 00000000
esi: cc800180   edi: c026f460   ebp: 0f0f0f0f   esp: c12fde50
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 1, stackpage=c12fd000)
Stack: c02c23e0 c02dc4c0 00000593 00000000 cc7fdc08 ffffffff 00000000 00000320 
       cc7fdc00 c01ac77c c12ee000 c02dc4c0 c12fe342 00000001 0000051e 00000000 
       c12fe340 c12fe342 00000001 00000593 c018150c c12ee000 c12fe340 00000001 
Call Trace: [<cc7fdc08>] [<cc7fdc00>] [<c01ac77c>] [<c018150c>] [<c0181584>] 
   [<c01adede>] [<c0181f04>] [<c01856f9>] [<c01aaeb9>] [<c0105013>] [<c010542c>] 
Code: 89 06 8a 03 24 0f 0f b6 d0 8b 44 24 18 23 04 97 31 e8 89 46 

>>EIP; c01b8f61 <fbcon_cfb8_putcs+1ad/2c8>   <=====
Trace; cc7fdc08 <END_OF_CODE+c51ad78/????>
Trace; cc7fdc00 <END_OF_CODE+c51ad70/????>
Trace; c01ac77c <fbcon_putcs+b8/d0>
Trace; c018150c <do_update_region+118/164>
Trace; c0181584 <update_region+2c/38>
Trace; c01adede <fbcon_switch+1aa/1bc>
Trace; c0181f04 <redraw_screen+e0/160>
Trace; c01856f9 <take_over_console+ed/188>
Trace; c01aaeb9 <register_framebuffer+f9/140>
Trace; c0105013 <init+7/114>
Trace; c010542c <kernel_thread+28/38>
Code;  c01b8f61 <fbcon_cfb8_putcs+1ad/2c8>
00000000 <_EIP>:
Code;  c01b8f61 <fbcon_cfb8_putcs+1ad/2c8>   <=====
   0:   89 06                     mov    %eax,(%esi)   <=====
Code;  c01b8f63 <fbcon_cfb8_putcs+1af/2c8>
   2:   8a 03                     mov    (%ebx),%al
Code;  c01b8f65 <fbcon_cfb8_putcs+1b1/2c8>
   4:   24 0f                     and    $0xf,%al
Code;  c01b8f67 <fbcon_cfb8_putcs+1b3/2c8>
   6:   0f b6 d0                  movzbl %al,%edx
Code;  c01b8f6a <fbcon_cfb8_putcs+1b6/2c8>
   9:   8b 44 24 18               mov    0x18(%esp,1),%eax
Code;  c01b8f6e <fbcon_cfb8_putcs+1ba/2c8>
   d:   23 04 97                  and    (%edi,%edx,4),%eax
Code;  c01b8f71 <fbcon_cfb8_putcs+1bd/2c8>
  10:   31 e8                     xor    %ebp,%eax
Code;  c01b8f73 <fbcon_cfb8_putcs+1bf/2c8>
  12:   89 46 00                  mov    %eax,0x0(%esi)

 <0>Kernel panic: Attempted to kill init!

Another prolem (which may be related) is that XFree's sis-drivers is also not working
(but only because the sis301's LCD port is not enabled correct ... - Without a special
hack of me and the VESA framebuffer I get simply a black screen (NO crash ...). Only the
latest revisions of the SIS chip are affected by this problems. Older ones seem to work
(at least in X). (I only have this new chip ...).

> Regards,
> 
> -- 
> Paul Mundt <le...@ch...>
> 



k33p h4ck1n6 René

-- 
René Rebe (Registered Linux user: #127875)
http://www.rene.rebe.myokay.net/
-Germany-

Anyone sending unwanted advertising e-mail to this address will be charged
$25 for network traffic and computing time. By extracting my address from
this message or its header, you agree to these terms.

[Linux-fbdev-devel] Re: sis630 - help needed debugging in the kernel

[Paul M. <le...@Ch...>]

On Mon, Jun 18, 2001 at 08:32:03PM +0200, Ren=E9 Rebe wrote:
> > Try booting at 640x480 with a color depth of 32. Then
> > try booting at a different resolution (1024x768) at the default color
> > depth. I want to see if its a error with the resolution setting or if=
 it
> > is a error with setting up the data relating to the color depth handl=
ing.=20
> > The results should give me some clue.
>=20
> I can't set the videomode for the driver ...? I tried:
>=20
> video=3Dsis:vesa:0x112
> video=3Dsis:xres:640,yres:480,depth:32
> video=3Dsis,xres:640,yres:480,depth:32
>=20
> Is there another way to tell the fb driver what mode to use??
>=20
Yep, in fbmem.c the name entry is "sisfb" as opposed to just "sis". Also,=
 the
driver requires that the mode is passed video a "mode:" argument as is
outlined in the sisfb_setup(). Take a look at drivers/video/sis/sis_main.=
h,
specifically sisbios_mode[] for a list of supported modes.

Something like:

video=3Dsisfb:mode:640x480x32

should do the job.

Regards,

--=20
Paul Mundt <le...@ch...>

[Linux-fbdev-devel] Re: sis630 - help needed debugging in the kernel

[René R. <ren...@gm...>]

On Sun, 17 Jun 2001 07:03:55 -0700 (PDT)
James Simmons <jsi...@tr...> wrote:

[...]

> Yes. It oops in fbcon_cfb8_putc. I haven't figured out yet what exactly
> caused it. I don't have this card to play with :-( Did you run the other
> test I suggested.

Never arrived here :-(. (Pleas cc me, since I'm not on this lists ...)

> Try booting at 640x480 with a color depth of 32. Then
> try booting at a different resolution (1024x768) at the default color
> depth. I want to see if its a error with the resolution setting or if it
> is a error with setting up the data relating to the color depth handling. 
> The results should give me some clue.

I can't set the videomode for the driver ...? I tried:

video=sis:vesa:0x112
video=sis:xres:640,yres:480,depth:32
video=sis,xres:640,yres:480,depth:32

Is there another way to tell the fb driver what mode to use??

I set the shared memory size from 16MB to 64 MB: results:
  sisfb: framebuffer at 0xe0000000, mapped to 0xc8800000, size 65536k
  sisfb: MMIO at 0xefce0000, mapped to 0xcc801000, size 128k
  Unable to handle kernel paging request at virtual address cc8002e0

old results:
  sisfb: framebuffer at 0xe0000000, mapped to 0xcb800000, size 16384k
  sisfb: MMIO at 0xefce0000, mapped to 0xcc801000, size 128k
  Unable to handle kernel paging request at virtual address cc800180

(Maybe some typo somewhere ??)

PS: I have more free time the next days -> shorter latency and more kernel
source read time ...

k33p h4ck1n6 René

-- 
René Rebe (Registered Linux user: #127875)
http://www.rene.rebe.myokay.net/
-Germany-

Anyone sending unwanted advertising e-mail to this address will be charged
$25 for network traffic and computing time. By extracting my address from
this message or its header, you agree to these terms.

[Linux-fbdev-devel] [PATCH] matroxfb updates for 2.4.5-ac15

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

Hi Alan,
  this patch for 2.4.5-ac15 adds following features/bugfixes to matroxfb driver:
(1) add support for G100 with SGRAM. It was needed to disable acceleration before.
(2) clears SRCORG and DSTORG accelerator registers on G200/G400/G450. Symptom
    was that after running XF4 with matrox's mga_drv console cannot use acceleration
    as nothing is paint by accelerator to visible screen. I can only hope that
    after XF exits DSTORG points somewhere to framebuffer and not to main memory, 
    otherwise it could cause couple of memory corruptions in the past...
(3) updated documentation, added matroxfb into MAINTAINERS and into CREDIT, so
    people know where to ask...
					Thanks for applying this,
						Petr Vandrovec
						van...@vc...

diff -urdN linux/CREDITS linux/CREDITS
--- linux/CREDITS	Mon Jun 18 12:23:11 2001
+++ linux/CREDITS	Mon Jun 18 15:41:10 2001
@@ -2869,6 +2869,7 @@
 N: Petr Vandrovec
 E: van...@vc...
 D: Small contributions to ncpfs
+D: Matrox framebuffer driver
 S: Chudenicka 8
 S: 10200 Prague 10, Hostivar
 S: Czech Republic
diff -urdN linux/Documentation/fb/matroxfb.txt linux/Documentation/fb/matroxfb.txt
--- linux/Documentation/fb/matroxfb.txt	Sun Nov 12 02:47:40 2000
+++ linux/Documentation/fb/matroxfb.txt	Mon Jun 18 15:48:01 2001
@@ -173,9 +173,9 @@
 mtrr     - enables write combining on frame buffer. It speeds up video accesses
            much. It is default. You must have MTRR support enabled in kernel
 	   and your CPU must have MTRR (f.e. Pentium II have them).
-sgram    - tells to driver that you have G200 with SGRAM memory. It has no
+sgram    - tells to driver that you have Gxx0 with SGRAM memory. It has no
            effect without `init'.
-sdram    - tells to driver that you have G200 with SDRAM memory.
+sdram    - tells to driver that you have Gxx0 with SDRAM memory.
            It is a default.
 inv24    - change timings parameters for 24bpp modes on Millenium and
            Millenium II. Specify this if you see strange color shadows around
@@ -279,7 +279,7 @@
  + 24bpp does not support correctly XF-FBDev on big-endian architectures.
  + interlaced text mode is not supported; it looks like hardware limitation,
    but I'm not sure.
- + G200 SGRAM/SDRAM is not autodetected.
+ + Gxx0 SGRAM/SDRAM is not autodetected.
  + maybe more...
 And following misfeatures:
  + SVGALib does not restore screen on exit.
@@ -336,7 +336,7 @@
 
 ACCEL, nofastfont
         8x16                 12x22                6x11
-	Millennium I  G200   Millennium I  G200    Millennium I G200
+	Millennium I  G200   Millennium I  G200   Millennium I  G200
 8bpp     7.79         7.24   13.55         7.78   30.00        21.01
 16bpp    9.13         7.78   16.16         7.78   30.00        21.01
 24bpp   14.17        10.72   18.69        10.24   34.99        21.01
@@ -344,7 +344,7 @@
 
 ACCEL, fastfont
         8x16                 12x22                6x11
-	Millennium I  G200    Millennium I G200   Millennium I  G200
+	Millennium I  G200   Millennium I  G200   Millennium I  G200
 8bpp     8.41         6.01    6.54         4.37   16.00        10.51
 16bpp    9.54         9.12    8.76         6.17   17.52        14.01
 24bpp   15.00        12.36   11.67        10.00   22.01        18.32
@@ -355,6 +355,8 @@
 	Millennium I  G200
 TEXT     3.29         1.50
 
+* Yes, it is slower than Millennium I.
+
 
 Dualhead G400
 =============
@@ -376,7 +378,22 @@
  + if you compiled it as module, you must insert i2c-matroxfb, matroxfb_maven
    and matroxfb_crtc2 into kernel.
 
+
+Dualhead G450
+=============
+Driver supports dualhead G450 with some limitations:
+ + secondary head shares videomemory with primary head. It is not problem
+   if you have 32MB of videoram, but if you have only 16MB, you may have
+   to think twice before choosing videomode.
+ + due to hardware limitation, secondary head can use only 16 and 32bpp
+   videomodes.
+ + secondary head is not accelerated.
+ + secondary head always powerups in 640x480@60-32 videomode. You have to use
+   fbset to change this mode.
+ + TV output is not supported
+ + kernel is not fully multihead ready, so some things are impossible to do.
+ + if you compiled it as module, you must insert matroxfb_g450 and matroxfb_crtc2
+   into kernel.
 	
-* Yes, it is slower than Millennium I.
 --
 Petr Vandrovec <van...@vc...>
diff -urdN linux/MAINTAINERS linux/MAINTAINERS
--- linux/MAINTAINERS	Mon Jun 18 12:23:12 2001
+++ linux/MAINTAINERS	Mon Jun 18 15:40:38 2001
@@ -895,6 +895,12 @@
 M:	za...@za...
 S:	Odd Fixes
 
+MATROX FRAMEBUFFER DRIVER
+P:	Petr Vandrovec
+M:	van...@vc...
+L:	lin...@li...
+S:	Maintained
+
 MEMORY TECHNOLOGY DEVICES
 P:	David Woodhouse
 M:	dw...@re...
diff -urdN linux/drivers/video/matrox/matroxfb_DAC1064.c linux/drivers/video/matrox/matroxfb_DAC1064.c
--- linux/drivers/video/matrox/matroxfb_DAC1064.c	Mon Jun 18 12:23:29 2001
+++ linux/drivers/video/matrox/matroxfb_DAC1064.c	Mon Jun 18 12:33:42 2001
@@ -4,7 +4,7 @@
  *
  * (c) 1998-2001 Petr Vandrovec <van...@vc...>
  *
- * Version: 1.52 2001/02/02
+ * Version: 1.53 2001/06/18
  *
  * See matroxfb_base.c for contributors.
  *
@@ -721,7 +721,8 @@
 	ACCESS_FBINFO(capable.vxres) = vxres_g100;
 	ACCESS_FBINFO(features.accel.has_cacheflush) = 1;
 	ACCESS_FBINFO(cursor.timer.function) = matroxfb_DAC1064_flashcursor;
-	ACCESS_FBINFO(capable.plnwt) = ACCESS_FBINFO(devflags.accelerator) != FB_ACCEL_MATROX_MGAG100;
+	ACCESS_FBINFO(capable.plnwt) = ACCESS_FBINFO(devflags.accelerator) == FB_ACCEL_MATROX_MGAG100
+			? ACCESS_FBINFO(devflags.sgram) : 1;
 
 	ACCESS_FBINFO(primout) = &m1064;
 
diff -urdN linux/drivers/video/matrox/matroxfb_accel.c linux/drivers/video/matrox/matroxfb_accel.c
--- linux/drivers/video/matrox/matroxfb_accel.c	Thu Aug 10 19:34:31 2000
+++ linux/drivers/video/matrox/matroxfb_accel.c	Mon Jun 18 15:52:55 2001
@@ -2,9 +2,9 @@
  *
  * Hardware accelerated Matrox Millennium I, II, Mystique, G100, G200 and G400
  *
- * (c) 1998,1999,2000 Petr Vandrovec <van...@vc...>
+ * (c) 1998-2001 Petr Vandrovec <van...@vc...>
  *
- * Version: 1.50 2000/08/10
+ * Version: 1.51 2001/06/18
  *
  * MTRR stuff: 1998 Tom Rini <tr...@ke...>
  *
@@ -129,6 +129,10 @@
 	mga_outl(M_YDSTORG, curr_ydstorg(MINFO));
 	if (ACCESS_FBINFO(capable.plnwt))
 		mga_outl(M_PLNWT, -1);
+	if (ACCESS_FBINFO(capable.srcorg)) {
+		mga_outl(M_SRCORG, 0);
+		mga_outl(M_DSTORG, 0);
+	}
 	mga_outl(M_OPMODE, mopmode);
 	mga_outl(M_CXBNDRY, 0xFFFF0000);
 	mga_outl(M_YTOP, 0);
diff -urdN linux/drivers/video/matrox/matroxfb_base.c linux/drivers/video/matrox/matroxfb_base.c
--- linux/drivers/video/matrox/matroxfb_base.c	Mon Jun 18 12:23:29 2001
+++ linux/drivers/video/matrox/matroxfb_base.c	Mon Jun 18 12:35:08 2001
@@ -4,7 +4,7 @@
  *
  * (c) 1998-2001 Petr Vandrovec <van...@vc...>
  *
- * Version: 1.52 2001/02/02
+ * Version: 1.53 2001/06/18
  *
  * MTRR stuff: 1998 Tom Rini <tr...@ke...>
  *
@@ -72,6 +72,9 @@
  *               "Ken Aaker" <kd...@rc...>
  *                     memtype extension (needed for GXT130P RS/6000 adapter)
  *
+ *               "Uns Lider" <uns...@mi...>
+ *                     G100 PLNWT fixes
+ *
  * (following author is not in any relation with this code, but his code
  *  is included in this driver)
  *
@@ -1409,7 +1412,7 @@
 
 #define DEVF_VIDEO64BIT		0x0001
 #define	DEVF_SWAPS		0x0002
-/* #define DEVF_recycled	0x0004 */
+#define DEVF_SRCORG		0x0004
 /* #define DEVF_recycled	0x0008 */
 #define DEVF_CROSS4MB		0x0010
 #define DEVF_TEXT4B		0x0020
@@ -1424,12 +1427,12 @@
 #define DEVF_G450DAC		0x4000
 
 #define DEVF_GCORE	(DEVF_VIDEO64BIT | DEVF_SWAPS | DEVF_CROSS4MB | DEVF_DDC_8_2)
-#define DEVF_G2CORE	(DEVF_GCORE | DEVF_ANY_VXRES | DEVF_MAVEN_CAPABLE | DEVF_PANELLINK_CAPABLE)
+#define DEVF_G2CORE	(DEVF_GCORE | DEVF_ANY_VXRES | DEVF_MAVEN_CAPABLE | DEVF_PANELLINK_CAPABLE | DEVF_SRCORG)
 #define DEVF_G100	(DEVF_GCORE) /* no doc, no vxres... */
 #define DEVF_G200	(DEVF_G2CORE)
 #define DEVF_G400	(DEVF_G2CORE | DEVF_SUPPORT32MB | DEVF_TEXT16B | DEVF_CRTC2)
 /* if you'll find how to drive DFP... */
-#define DEVF_G450	(DEVF_GCORE | DEVF_ANY_VXRES | DEVF_SUPPORT32MB | DEVF_TEXT16B | DEVF_CRTC2 | DEVF_G450DAC)
+#define DEVF_G450	(DEVF_GCORE | DEVF_ANY_VXRES | DEVF_SUPPORT32MB | DEVF_TEXT16B | DEVF_CRTC2 | DEVF_G450DAC | DEVF_SRCORG)
 
 static struct board {
 	unsigned short vendor, device, rev, svid, sid;
@@ -1556,7 +1559,7 @@
 		DEVF_G200,
 		230000,
 		&vbG200,
-		"unknown G200 (AGP)"},
+		"G200 (AGP)"},
 	{PCI_VENDOR_ID_MATROX,	PCI_DEVICE_ID_MATROX_G400_AGP,	0x80,
 		PCI_SS_VENDOR_ID_MATROX,	PCI_SS_ID_MATROX_MILLENNIUM_G400_MAX_AGP,
 		DEVF_G400,
@@ -1568,13 +1571,13 @@
 		DEVF_G400,
 		300000,
 		&vbG400,
-		"unknown G400 (AGP)"},
+		"G400 (AGP)"},
 	{PCI_VENDOR_ID_MATROX,	PCI_DEVICE_ID_MATROX_G400_AGP,	0xFF,
 		0,			0,
 		DEVF_G450,
 		500000,		/* ??? vco goes up to 900MHz... */
 		&vbG400,
-		"unknown G450 (AGP)"},
+		"G450 (AGP)"},
 #endif
 	{0,			0,				0xFF,
 		0,			0,
@@ -1611,6 +1614,7 @@
 
 	printk(KERN_INFO "matroxfb: Matrox %s detected\n", b->name);
 	ACCESS_FBINFO(capable.plnwt) = 1;
+	ACCESS_FBINFO(capable.srcorg) = b->flags & DEVF_SRCORG;
 	ACCESS_FBINFO(devflags.video64bits) = b->flags & DEVF_VIDEO64BIT;
 	if (b->flags & DEVF_TEXT4B) {
 		ACCESS_FBINFO(devflags.vgastep) = 4;
@@ -2527,7 +2531,7 @@
 MODULE_PARM(mtrr, "i");
 MODULE_PARM_DESC(mtrr, "This speeds up video memory accesses (0=disabled or 1) (default=1)");
 MODULE_PARM(sgram, "i");
-MODULE_PARM_DESC(sgram, "Indicates that G200/G400 has SGRAM memory (0=SDRAM, 1=SGRAM) (default=0)");
+MODULE_PARM_DESC(sgram, "Indicates that G100/G200/G400 has SGRAM memory (0=SDRAM, 1=SGRAM) (default=0)");
 MODULE_PARM(inv24, "i");
 MODULE_PARM_DESC(inv24, "Inverts clock polarity for 24bpp and loop frequency > 100MHz (default=do not invert polarity)");
 MODULE_PARM(inverse, "i");
diff -urdN linux/drivers/video/matrox/matroxfb_base.h linux/drivers/video/matrox/matroxfb_base.h
--- linux/drivers/video/matrox/matroxfb_base.h	Fri Feb  9 19:30:23 2001
+++ linux/drivers/video/matrox/matroxfb_base.h	Mon Jun 18 12:50:08 2001
@@ -492,6 +492,7 @@
 		int		cross4MB;
 		int		text;
 		int		plnwt;
+		int		srcorg;
 			      } capable;
 	struct {
 		unsigned int	size;
@@ -738,6 +739,7 @@
 
 /* G200 only */
 #define M_SRCORG	0x2CB4
+#define M_DSTORG	0x2CB8
 
 #define M_RAMDAC_BASE	0x3C00
 

[Linux-fbdev-devel] PATCH: tdfxfb.c with alligned reads in putc and putcs

[Martin E. <Mar...@ma...>]

I have modified tdfxfb.c so that putc and putcs only use alligned reads from 
the font, to avoid problems on architectures which don't allow unalligned 
reads.

What do you think about this code ?