Re: Re: board with broken vga ...

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