Re: Re: board with broken vga ...

Re: Re: board with broken vga ...

[Petr Vandrovec]

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
                                                


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: board with broken vga ...

[Sven]

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

Friendly,

Sven Luthe


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: board with broken vga ...

[Sven LUTHER]

On Mon, Jul 22, 2002 at 11:07:28PM +0200, Petr Vandrovec wrote:
> 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.

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 : À^KÄ^KÈ.
  * 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 = 25, osr = 160.
SVEN : vc_resize [0] : ol = c11223c0, nl = c7e42000.
  * i use screenbuf instead of origin for the copy.
SVEN : vc_resize [0] : oss = 4000, ss = 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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: board with broken vga ...

[Petr Vandrovec]

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
                                                    


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: board with broken vga ...

[Sven]

> 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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: board with broken vga ...

[Petr Vandrovec]

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
                                                        


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: board with broken vga ...

[Sven]

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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: board with broken vga ...

[Petr Vandrovec]

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
                                                            


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: board with broken vga ...

[Sven]

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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: board with broken vga ...

[Petr Vandrovec]

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
                                                    


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: board with broken vga ...

[Sven]

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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf