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

Re: [Linux-fbdev-devel] aty128 framebuffer - cannot change resolution

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

Use this:

video=3Daty128fb:<xres>x<yres>[-<bpp>][@refresh]

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'\_   _/`\
 \___)=3D(___/

On Fri, 19 Jul 2002, Hanno B=F6ck wrote:

> i have a problem with the aty128fb. It always starts with 640x480-resolut=
ion, although i have applied vga=3D791 (should be 1024x768) commandline.
>
> It is an ATI Rage 128 RF/SG AGP and Kernel 2.4.18.
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
>

[Linux-fbdev-devel] 2.5 vs. aty128fb & radeonfb

[Benjamin H. <be...@ke...>]

Hi !

Does somebody plans to update 2.5 with versions of these drivers that
at least build ? They have been broken for ages now.

If not, then I'll do my own fixing and submit that.

Regards,
Ben.

Re: [Linux-fbdev-devel] [PATCH] Designated initializer patches for 2.5.28 drivers/video/

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

> Hi all,
>
> 	Please include and forward to Linus on next update.  I can't
> find an overall drivers/video/ maintainer, so I'm trying the mailing
> list first.

Its me and Geert. I'm applying the changes to the fbdev BK repository.

[Linux-fbdev-devel] [PATCH] Designated initializer patches for 2.5.28 drivers/video/

[Rusty R. <ru...@ru...>]

Hi all,

	Please include and forward to Linus on next update.  I can't
find an overall drivers/video/ maintainer, so I'm trying the mailing
list first.

Thanks,
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

[Linux-fbdev-devel] [PATCH] penguin logo code

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

### Comments for changeset
The penguin logo resides in normal RAM, not in frame buffer memory, so we must
not use fb_readb()

### Comments for drivers/video/fbcon.c
The penguin logo resides in normal RAM, not in frame buffer memory, so we must
not use fb_readb()

--- linux-2.4.19-rc3/drivers/video/fbcon.c	Fri Feb 22 16:28:32 2002
+++ linux-m68k-2.4.19-rc3/drivers/video/fbcon.c	Mon Jul 22 21:45:01 2002
@@ -2417,7 +2417,7 @@
 		else
 		    dst = fb + y1*line + x/8;
 		for( x1 = 0; x1 < LOGO_LINE; ++x1 )
-		    fb_writeb(fb_readb(src++) ^ inverse, dst++);
+		    fb_writeb(*src++ ^ inverse, dst++);
 	    }
 	    done = 1;
 	}

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

[Linux-fbdev-devel] [PATCH] fbdev updates.

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

Hi!

  This changeset includes updates from the m68k group and removal of the
obsolete XPMAC code for the PPC platform. A few bug fixes as well.

http://fbdev.bkbits.net/fbdev-2.5

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'\_   _/`\
 \___)=(___/

Re: [Linux-fbdev-devel] Re: board with broken vga ...

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

On Mon, Jul 22, 2002 at 11:07:28PM +0200, Petr Vandrovec wrote:
> On 22 Jul 02 at 23:00, Sven wrote:
>=20
> > > Just put it into vc_screenbuf after register_framebuffer() returns,=
 and
> > > force redraw...
> >=20
> > mmm, will try.
> >=20
> > BTW, how can i force a redraw from pm3fb ?
> >=20
> > > If you'll override save_screen, and you'll put set_origin() into vi=
sual_init,
> >=20
> > NO, just tried, i got no more display, and the box hanged ...
>=20
> Oops. fbcon_set_origin will call scrolldelta which ... So what about si=
mple
> origin =3D screenbuf in visual_init ? It should have no side effects.

I gave it another try, checking some stuff as i went.

Latest state is :

I copy the console data by overriding the vgacon save_screen function.

i have tested that in vc_resize, the data is effectively where i want
it, but that the origin function is not poiting to it, so i initialized
ol with screenbuf and not origin.

The result is the same as when i tried to simply clear the space instead
of copying, which seems strange to me. Even filling them with a bogus
character doesn't seem to work.

Also, i manage to clear only the top of the screen, the bottom of it, in
a distance the size of the logo still contains the the garbage.

The bottom of the 80x25 region of the screen that is.

here are the dumps i made :

SVEN : pm3fb.common_init : l_fb_info->v_fb is c8830000.
SVEN : Saving the console data : ...done
FB@880 has : L 4c 07 00 00 00 00 00 00.
FB@880 has : 0007.
sven@880 has : 074c.
  * here is position 880 of the vga console data, the L that starts the
  * log.
SVEN : Am using my own function ...
SVEN : sven@880 has : Linux.
SVEN : c->vc_screenbuf is c11223c0.
SVEN : c->vc_screenbuf@880 has : Linux.
SVEN : c->vc_origin is c00bbd40.
  * vc_origin is pointing to some bogus place.
SVEN : c->vc_origin@880 has : =C0^K=C4^K=C8.
  * and holds bogus data.
SVEN : vc_resize [0] screenbuf is c11223c0.
SVEN : vc_resize [0] origin is c00bbe80.
  * in vc_resize they are the same.
SVEN : vc_resize [0] kmallocated a new screenbuf at c7e42000.
SVEN : vc_resize [0] : oll =3D 25, osr =3D 160.
SVEN : vc_resize [0] : ol =3D c11223c0, nl =3D c7e42000.
  * i use screenbuf instead of origin for the copy.
SVEN : vc_resize [0] : oss =3D 4000, ss =3D 7400.
SVEN : ol@880 has : Linux.
SVEN : ol@880 has : 074c.
SVEN : nl@880 has :      .
  * and verify that ol holds the console data (nl is empty still).
Console: switching to colour frame buffer device 100x37

I did not manage to do real tests after the copying was done though.
But, i see nothing on the screen.

Friendly,

Sven Luther

[Linux-fbdev-devel] Dual Athlon crashing with VESAfb and Rivafb

[<de...@re...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I have put together a dual Athlon machine (K7D Master mobo with the AMD 7=
60MPX=20
chipset) and GeForce4 Ti4400 video card, and my only grip with it so far =
is=20
the inability to run my display with a framebuffer device. VESAfb locks m=
y=20
machine hard, while Rivafb leaves me staring at a blank screen (though th=
e=20
system keeps loading). That happened on 2.4.19-pre2 with the RML's preemp=
t=20
patch (configured for SMP, preemption enabled, VESAfb and Rivafb built-in=
=20
into the kernel). Now I have updated to 2.4.19-rc3, and VESAfb keeps lock=
ing=20
the machine hard, but I can't load Rivafb any longer, passing the boot-ti=
me=20
parameter video=3Driva:1024x768-32@60 still loads with a plain text conso=
le,=20
and `dmesg | grep riva' doesn't show up anything.

Is this a known problem? Any ideas on how to fix it? If more information =
is=20
needed, let me know and I will provide it.

Thanks

D=E9cio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj08yiwACgkQZ4XkjV48x2dddwCcDWDSL7dvt0aS/OXv5WPCuTtJ
KQIAni61GQ+XO5aBszskX8jAxtLJG9fy
=3DVw/p
-----END PGP SIGNATURE-----

Re: [Linux-fbdev-devel] Re: board with broken vga ...

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

Ok, will try this and tell you the result (but tommorow).

Friendly,

Sven Luthe

Re: [Linux-fbdev-devel] Re: board with broken vga ...

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

On 22 Jul 02 at 23:00, Sven wrote:

> > Just put it into vc_screenbuf after register_framebuffer() returns, and
> > force redraw...
> 
> mmm, will try.
> 
> BTW, how can i force a redraw from pm3fb ?
> 
> > If you'll override save_screen, and you'll put set_origin() into visual_init,
> 
> NO, just tried, i got no more display, and the box hanged ...

Oops. fbcon_set_origin will call scrolldelta which ... So what about simple
origin = screenbuf in visual_init ? It should have no side effects.

> How i do it :
> 
> i copy the data in pm3fb just after i first map the framebuffer. i hold it in a special
> array in pm3fb (for now).
> 
> But then, maybe i should see if the location of the set_origin should be changed, maybe i could do it in vc_resize for now.
> 
> BTW, in the first case, i will see the screen flashing shortly with the garbage i see now, and then work ok, isn't it ? 

Yes.

> And i would need to handle resolution changes myself ?

Yes. Or you can copy data just line by line, instead of like one big chunk.
Yes, it is duplicating of vc_resize code.
                                                Petr Vandrovec
                                                

Re: [Linux-fbdev-devel] Re: board with broken vga ...

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

> Just put it into vc_screenbuf after register_framebuffer() returns, and
> force redraw...

mmm, will try.

BTW, how can i force a redraw from pm3fb ?

> If you'll override save_screen, and you'll put set_origin() into visual_init,

NO, just tried, i got no more display, and the box hanged ...

How i do it :

i copy the data in pm3fb just after i first map the framebuffer. i hold it in a special
array in pm3fb (for now).

But then, maybe i should see if the location of the set_origin should be changed, maybe i could do it in vc_resize for now.

BTW, in the first case, i will see the screen flashing shortly with the garbage i see now, and then work ok, isn't it ? And i would need to handle resolution changes myself ?

Friendly,

Sven Luther:q

Re: [Linux-fbdev-devel] Re: board with broken vga ...

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

On 22 Jul 02 at 22:40, Sven wrote:
> 
> What would solve my problem in the easiest way would be to have some 
> framebuffer restore hook or something in the fbdev driver, which would get called
> in take_over_screen or something such, after the screen has been resized ?

Just put it into vc_screenbuf after register_framebuffer() returns, and
force redraw...
 
> Or Maybe simply tell vc_resize that we use a special way of reading the framebuffer.
> 
> Or i should implement the trick you use for setting the card in 
> graphic mode later on in the setvar stuff ?

If you'll override save_screen, and you'll put set_origin() into visual_init,
I believe that it will work:

(1) in take_over_console, copy data to screenbuf using your own save_screen.
(2) now vc_resize (with prior set_origin) will copy data from old screenbuf
    to reallocated screenbuf (instead of from videoram to reallocated
    screenbuf).
(3) and update_screen() will just paint data which are already on screen
    if resolution changed. If resolutions matched, it will put data on the
    screen.

                                                    Petr
                                                    

Re: [Linux-fbdev-devel] Re: board with broken vga ...

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

Hello, ...

Sorry, i cannot do propper cut&paste here, as i am mailing over a console with lot of debug message showing :(((

Anyway, ...

Yes, vc_resize get calledafter we call register_framebuffer, and before the first set_origin, and i guess this
is the reason for our problems.

What would be a solution, would be not to override the vga save_screen as i do, 
but copy the data (which i now hold in a private structure of pm3fb) after vc_resize was done.

I did a bit of looking, but couldn't find a proper place to do this.

And yes, i am working on linus 2.5.25, without further patches (well pm3fb does need 
to get adapted to the new way, but idon't feel that i undertsood 
sufficiently what is going on to do the adapation (in the little time i have for this).


As for the screenbuf, i don't think there is any strange set_origin going on, but
then it was not me who wrote pm3fb, and i couldn't say for sure.


The first screenbuf, and the one i am copying to, is the one from vgacon, 
since i did override the vgacon save_screen, i guess this is notsomething that should be happening.

Mmm, how does the standard way handle things ? vgacon save_screen fills the screenbuf, and
vc_resize does copy the stuff over to the new screenbuf ?

Yes, i think that it happens in vc_resize, i will look more to see if i can spot the  
part that moves data around and check if it does it right or not.



Yes, the framebuffer format is <> frome what svgacon save_screen expect.

(i get the console chars every other 8 bytes, with probably the attributes at an 4 byte offset or something such.)

Mmm, is the fact that vc_resize uses the origin directlt not a buggy behavior ?

What do we have vgacon_save_screen for then, if it never gets used ?

Mmm, maybe vgacon_save_screen is just for saving stuff when we switch vga console, and has nothing
should not be used as we use it, but togeher with vgacon_switch.



What would solve my problem in the easiest way would be to have some 
framebuffer restore hook or something in the fbdev driver, which would get called
in take_over_screen or something such, after the screen has been resized ?

Or Maybe simply tell vc_resize that we use a special way of reading the framebuffer.

Or i should implement the trick you use for setting the card in 
graphic mode later on in the setvar stuff ?

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Re: board with broken vga ...

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

On 22 Jul 02 at 21:58, Sven wrote:

> I did a bit more looking, and found that :
> 
> Jul 22 21:49:32 iliana kernel: SVEN : c->vc_screenbuf is -1055775808

Having them hexadecimal would be much better... c11223c0... bootmem.
 
> screen buffer is set to that when i overwrite the vgacon save_scree function, and here i save
> it (printed with %ld).
> 
> Jul 22 21:49:32 iliana kernel: SVEN : set_origin : screenbuf is -941350912.

c7e42000... kmalloc

> Jul 22 21:49:32 iliana kernel: SVEN : set_origin : origin is -1072968800.

c00bcba0... inside VGA framebuffer.

> when set_origin is first called (not from do_update_screen) after that, it held this values.
> 
> Clearly the screenbuf is not the same.

Probably resize triggers in. But you are doing something wrong - do
you work with Linus tree or on the top of James work? Inside (and after)
do_update_region you should not have origin pointing to the VGA
framebuffer anymore, it must point to screenbuf area! Or do you
implement some strange set_origin method?
 
> the nredraw_screen is called, which calls again set_origin, and then calls 
> do_update_region as follows :
> 
> Jul 22 21:49:32 iliana kernel: SVEN : do_update_region : + start = -941350912, count = 3700
> 
> here we see that the screenbuf used is the wrongly set one, 
> not the one i copied the stuff to.

Only place which does realloc is vc_resize, and code here should
properly move data. 
 
> Mmm, i suppose that what happens is that the screenbuf is different 
> for fbcon and vgacon or something such, and this seems clearly the reason
> for lot of garbage appearing on my screen, is it not ?

I've got an idea: vc_resize reads data from vc's origin, unconditionally,
without call to save_screen! So if your framebuffer layout is not
compatible with VGA, you are lost. 
fbcon_init -> fbcon_setup -> vc_resize_con -> origin leaved unset...
Adding call to set_origin(currcons) into visual_init, just before
call to sw->con_init() may fix problem. Or maybe it will just make problem
even worse? Who knows?
                                                        Petr
                                                        

Re: [Linux-fbdev-devel] Re: board with broken vga ...

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

Hello, ...

I did a bit more looking, and found that :

Jul 22 21:49:32 iliana kernel: SVEN : c->vc_screenbuf is -1055775808

screen buffer is set to that when i overwrite the vgacon save_scree function, and here i save
it (printed with %ld).

Jul 22 21:49:32 iliana kernel: SVEN : set_origin : screenbuf is -941350912.
Jul 22 21:49:32 iliana kernel: SVEN : set_origin : origin is -1072968800.

when set_origin is first called (not from do_update_screen) after that, it held this values.

Clearly the screenbuf is not the same.

(and contains only garbage).

the nredraw_screen is called, which calls again set_origin, and then calls 
do_update_region as follows :

Jul 22 21:49:32 iliana kernel: SVEN : do_update_region : + start = -941350912, count = 3700

here we see that the screenbuf used is the wrongly set one, 
not the one i copied the stuff to.

Mmm, i suppose that what happens is that the screenbuf is different 
for fbcon and vgacon or something such, and this seems clearly the reason
for lot of garbage appearing on my screen, is it not ?

Friendly,

Sven Luther:wq

Re: [Linux-fbdev-devel] Re: board with broken vga ...

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

On 22 Jul 02 at 19:46, Sven wrote:
> PEtr wrote : 
> > thought that:
> >   take_over_console -> update_screen(x) -> redraw_screen(x,0) ->
> > (1) set vc_origin to vc_screenbuf in set_origin()
> > (2) paint picture through do_update_region() -> con_getxy, con_putcs
> > vc_screenbuf is accessed through screenbuf macro from console_macros.h.
> > It is very hard to find anything in console.c. I use simple rule:
> > all X variables you see in function are vc_X members of vt struct unless
> > you see definition of X on your screen.
> 
> Well, i did search for screenbuf and not vc_screenbuf, and i did find the macros.
> 
> I did not find any reference in anything excepth vgacon_switch and vgacon_save_screen.

drivers/char/console.c:set_origin(), vc_resize(), ...
 
> is vc_screenbuf still part of the framebuffer memory, i thought it was some other main memory, a ...

vc_screenbuf is alloc_bootmem() or kmalloc(if screen resize happens) memory.
vgacon uses its own vgacon_set_origin(), which sets vc_origin to
VGA framebuffer, while with fbcon it sets vc_origin to vc_screenbuf.

> BAsically, i am now sure that i copy the right data to the screenbuf (well for the character data, i just use empty attributes, is that ok for now ?, where can i find the attribute format ?).

scr_write() will take a care of byteswapping. If in 8bit characters,
upper 8 bits are attr, low 8 bits is character.

> But it seems the problem is when copying the stuff back to the screen that something goes wrong.
> 
> I suspect that it is not the correct data (the one in screenbuf) that is taken or something like that.

Just idea: force your fbdev to use same resolution as vgacon
(80x25, 640x400, or change vgacon resolution to 80x30 if your fbdev uses
640x480) so that vc_resize path is not triggered. It does some copying
too.
                                                            Petr
                                                            

Re: [Linux-fbdev-devel] Re: board with broken vga ...

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

PEtr wrote : 
> thought that:
>   take_over_console -> update_screen(x) -> redraw_screen(x,0) ->
> (1) set vc_origin to vc_screenbuf in set_origin()
> (2) paint picture through do_update_region() -> con_getxy, con_putcs
> vc_screenbuf is accessed through screenbuf macro from console_macros.h.
> It is very hard to find anything in console.c. I use simple rule:
> all X variables you see in function are vc_X members of vt struct unless
> you see definition of X on your screen.

Well, i did search for screenbuf and not vc_screenbuf, and i did find the macros.

I did not find any reference in anything excepth vgacon_switch and vgacon_save_screen.

Also :

is vc_screenbuf still part of the framebuffer memory, i thought it was some other main memory, a ...

Mmm, i will have to look more at it, thanks for the info thpugh.

BAsically, i am now sure that i copy the right data to the screenbuf (well for the character data, i just use empty attributes, is that ok for now ?, where can i find the attribute format ?).

But it seems the problem is when copying the stuff back to the screen that something goes wrong.

I suspect that it is not the correct data (the one in screenbuf) that is taken or something like that.

But then, maybe i am worng (well most probably i am wrong).

Friendly,

Sven Luther:wq

Re: [Linux-fbdev-devel] Re: board with broken vga ...

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

On 22 Jul 02 at 19:23, Sven LUTHER wrote:

> Petr wrote :
> > your drivers's init
> >    --> look and init devices
> >        --> call register_framebuffer
> >            --> VGACON reads contents of VGA buffer
> >            --> call to fbdev setvar
> >            --> upper layer restores screen
> > ...
> 
> Mmm, i did manage to override the vga save_screen function, and copy the
> good values into vc_sceenbuf, but to no avail.
> 
> What frustrates me is that i cannot find any reference to some piece of
> code using the data in vc_sceenbuf to write to the screen again.
> 
> How exactly does the upper layer restore the screen ?

I thought that:
  take_over_console -> update_screen(x) -> redraw_screen(x,0) ->
(1) set vc_origin to vc_screenbuf in set_origin()
(2) paint picture through do_update_region() -> con_getxy, con_putcs

vc_screenbuf is accessed through screenbuf macro from console_macros.h.
It is very hard to find anything in console.c. I use simple rule:
all X variables you see in function are vc_X members of vt struct unless
you see definition of X on your screen.
                                                    Petr Vandrovec
                                                    

[Linux-fbdev-devel] Re: board with broken vga ...

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

Petr wrote :
> your drivers's init
>    --> look and init devices
>        --> call register_framebuffer
>            --> VGACON reads contents of VGA buffer
>            --> call to fbdev setvar
>            --> upper layer restores screen
> ...

Mmm, i did manage to override the vga save_screen function, and copy the
good values into vc_sceenbuf, but to no avail.

What frustrates me is that i cannot find any reference to some piece of
code using the data in vc_sceenbuf to write to the screen again.

How exactly does the upper layer restore the screen ?

Friendly,

Sven Luther

[Linux-fbdev-devel] aty128 framebuffer - cannot change resolution

[Hanno B. <ha...@gm...>]

i have a problem with the aty128fb. It always starts with 640x480-resolution, although i have applied vga=791 (should be 1024x768) commandline.

It is an ATI Rage 128 RF/SG AGP and Kernel 2.4.18.

Re: [Linux-fbdev-devel] board with broken vga ...

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

On Thu, Jul 18, 2002 at 01:36:42PM +0200, Sven Luther wrote:
> On Thu, Jul 18, 2002 at 11:42:57AM +0200, Petr Vandrovec wrote:
> > On 18 Jul 02 at 9:51, Sven Luther wrote:
> > > 
> > > Ok, that said, i suppose ours are the only boards with such problems,
> > > but since there is so much taken out of the drivers in your new setup
> > > and put in a common place, would it not solve this problem if there were
> > > an additional function which driver could provide (or fill in NULL if
> > > there was no proble), for retrieving this data, which fbcon can write
> > > back later on ?
> > 
> > Unfortunately there is no such hook. Fortunately call sequence is:
> 
> Yes, i know, but would such a hook be a good addition for the new API or
> something ? 
> 
> Altough, it is true that maybe only pm2fb and pm3fb will make use of it,
> it would be cleaner than patching vgacon code for it.
> 
> > your drivers's init
> >    --> look and init devices
> >        --> call register_framebuffer
> >            --> VGACON reads contents of VGA buffer
> 
> So vgacon is responsible for (wrongly) reading the text data from the
> board.
> 
> >            --> call to fbdev setvar
> >            --> upper layer restores screen
> > ...
> > With matroxfb I moved all initialization which changes framebuffer layout
> > to the setvar call, and so VGACON finds hardware in VGA, and not MMIO,
> > state.
> 
> Mmm, that may be an idea, provided the normal VGA stuff is not broken.
> 
> > You can look at drivers/char/console.c: take_over_console calls
> > save_screen, which in turn calls con_save_screen method of vgacon.
> > So you can try directly overwritting vgacon's savescreen procedure
> > 
> > extern struct consw vga_con;
> > vga_con.con_save_screen = myOwnSaveScreen;

I tried this, but without success, well it worked, but the corruption is
still there.

when i read ->vc_origin, i can see somewhat of the stuff i have in my
scren after the switch.

when i read the framebuffer directly, i get the console as it should be
(at every 8 bytes, so i guess the attributes are in some of the other 7
bytes, either just behind or before it, or at an 4 bytes offset).

I tried writing plain 'X' chars to the ->vc_screenbuf, but nothing
happens (but the stuff i read directly has now 'X's in background as
below :

880Linux version 2.5.25 (luther@iliana) (gcc version 2.95.4 20011002
(Debian prerel
960ease)) #14 Thu Jul 18 17:37:48 CEST 2002XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1040Video mode to be used for restore is f00XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1120BIOS-provided physical RAM map:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1200 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)XXXXXXXXXXXXXXXXXXXXXXXX
1280 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)XXXXXXXXXXXXXXXXXXXXXX
1360 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)XXXXXXXXXXXXXXXXXXXXXX

What seems strange is that i read these stuff before calling
register_framebuffer, so how can the 'X' i write there afterward appear
?

Clearly something strange is going on, i will investigate more.

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] board with broken vga ...

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

On Thu, Jul 18, 2002 at 11:42:57AM +0200, Petr Vandrovec wrote:
> On 18 Jul 02 at 9:51, Sven Luther wrote:
> > 
> > Ok, that said, i suppose ours are the only boards with such problems,
> > but since there is so much taken out of the drivers in your new setup
> > and put in a common place, would it not solve this problem if there were
> > an additional function which driver could provide (or fill in NULL if
> > there was no proble), for retrieving this data, which fbcon can write
> > back later on ?
> 
> Unfortunately there is no such hook. Fortunately call sequence is:

Yes, i know, but would such a hook be a good addition for the new API or
something ? 

Altough, it is true that maybe only pm2fb and pm3fb will make use of it,
it would be cleaner than patching vgacon code for it.

> your drivers's init
>    --> look and init devices
>        --> call register_framebuffer
>            --> VGACON reads contents of VGA buffer

So vgacon is responsible for (wrongly) reading the text data from the
board.

>            --> call to fbdev setvar
>            --> upper layer restores screen
> ...
> With matroxfb I moved all initialization which changes framebuffer layout
> to the setvar call, and so VGACON finds hardware in VGA, and not MMIO,
> state.

Mmm, that may be an idea, provided the normal VGA stuff is not broken.

> You can look at drivers/char/console.c: take_over_console calls
> save_screen, which in turn calls con_save_screen method of vgacon.
> So you can try directly overwritting vgacon's savescreen procedure
> 
> extern struct consw vga_con;
> vga_con.con_save_screen = myOwnSaveScreen;
> 
> if you find that your fbdev is primary VGA device. Of course it is
> not tested, and I cannot recommend doing that...

Ok, i will look at it, thanks.

Friendly,

Sven Luther
>                                                     Petr
>                                                     

Re: [Linux-fbdev-devel] board with broken vga ...

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

On 18 Jul 02 at 9:51, Sven Luther wrote:
> 
> Ok, that said, i suppose ours are the only boards with such problems,
> but since there is so much taken out of the drivers in your new setup
> and put in a common place, would it not solve this problem if there were
> an additional function which driver could provide (or fill in NULL if
> there was no proble), for retrieving this data, which fbcon can write
> back later on ?

Unfortunately there is no such hook. Fortunately call sequence is:

your drivers's init
   --> look and init devices
       --> call register_framebuffer
           --> VGACON reads contents of VGA buffer
           --> call to fbdev setvar
           --> upper layer restores screen
...
With matroxfb I moved all initialization which changes framebuffer layout
to the setvar call, and so VGACON finds hardware in VGA, and not MMIO,
state.

You can look at drivers/char/console.c: take_over_console calls
save_screen, which in turn calls con_save_screen method of vgacon.
So you can try directly overwritting vgacon's savescreen procedure

extern struct consw vga_con;
vga_con.con_save_screen = myOwnSaveScreen;

if you find that your fbdev is primary VGA device. Of course it is
not tested, and I cannot recommend doing that...
                                                    Petr
                                                    

[Linux-fbdev-devel] board with broken vga ...

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

Hello, ...

i am looking again at pm3fb (still old style one though).

Permedia3 (and probably permedia2 also) has a problem with accessing vga
stuff in mmio mode, which makes it not work correctly when the text from
the vga console mode is copied over to the fbcon at the switch.

I have the understanding that you moved this stuff over to some other
place and not the pm3fb driver itself (but where ?)

I now know how to get this data by looking at the framebuffer directly
(it is found starting at framebuffer addr + 0 in 8 byte steps.), but
need to know how i can hook it in, to write it back.

Also, the size of this text is somewhat of a mistery for me still.

Ok, that said, i suppose ours are the only boards with such problems,
but since there is so much taken out of the drivers in your new setup
and put in a common place, would it not solve this problem if there were
an additional function which driver could provide (or fill in NULL if
there was no proble), for retrieving this data, which fbcon can write
back later on ?

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Card's view of framebuffer offset i

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

On 15 Jul 02 at 4:56, Ville Syrj=E4l=E4 wrote:
> On Mon, Jul 15, 2002 at 02:02:14AM +0200, Petr Vandrovec wrote:
> > On Sun, Jul 14, 2002 at 04:10:29PM +0300, Ville Syrj=E4l=E4 wrote:
> > > Is there a way to ge the framebuffer offset to userspace? I hacked
> > > DirectFB to draw to the crtc2 display but currently I've had to hard=
code
> > > the framebuffer offset. So I need something I can feed to tmy G400.
> > 
> > In what environment? With matroxfb you have special framebuffer which
> > is displayed by CRTC2 engine.
> 
> > Offset is not explicitly exported, but
> > if you'll take low 24 bits from fb_start, you'll get offset on
> > G400/G450/G550 devices.
> 
> I don't see such a thing anywhere. Do you mean smem_start? Ok just tried
> with (smem_start + offset & 0x1ffffff) and it works for both heads. So
> that's actually 25 bits. Maybe I should just use 28 bits to accomodate
> larger framebuffers?

No. You must use exactly 25 bits on G400/G450/G550 series, because of
upper 7 bits are random: framebuffer apperture is 32MB on them, and upper
7 bits specify framebuffer position in PCI MMIO address space.
                                                Petr Vandrovec