Re: Re: board with broken vga ...

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

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