Finally found why 2.6.x has troubles with taking over vgacon

2 messages, 2 authors, 2004-07-04 · open the first message on its own page

Finally found why 2.6.x has troubles with taking over vgacon

From: Petr Vandrovec <hidden>
Date: 2004-07-03 19:56:20

Hi Antonio,
  yesterday I finally found why 2.6.x has problems with taking over vgacon.
Problem is that take_over_console does:


  if (IS_VISIBLE)
    save_screen(i);
  ...
  visual_init(i, 0);
  ...

so code nicely saves screen contents, and calls visual_init, which calls 
fbcon's init, which in turn can issue vc_resize. And this vc_resize will
trigger read from vc->vc_origin. But vc_origin still points to videomemory,
not to the buffer where save_screen() copied its data.

  In my fbcon (http://platan.vc.cvut.cz/ftp/pub/linux/matrox-latest/matroxfb-2.6.7-c1784.tar.gz)
after I put

  origin = visual_origin = screenbuf;

below save_screen call, and removed clearing screen from radeon sources 
both radeonfb and matroxfb were able to take over vgacon, without any 
randomly colored characters on screen.

  It also allows for removing special fillrect clear, as now code
which clears upper few lines of logo area actually works...
						Best regards,
							Petr Vandrovec




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Finally found why 2.6.x has troubles with taking over vgacon

From: Antonino A. Daplas <hidden>
Date: 2004-07-04 00:57:23

On Sunday 04 July 2004 03:56, Petr Vandrovec wrote:
Hi Antonio,
  yesterday I finally found why 2.6.x has problems with taking over vgacon.
Problem is that take_over_console does:


  if (IS_VISIBLE)
    save_screen(i);
  ...
  visual_init(i, 0);
  ...

so code nicely saves screen contents, and calls visual_init, which calls
fbcon's init, which in turn can issue vc_resize. And this vc_resize will
trigger read from vc->vc_origin. But vc_origin still points to videomemory,
not to the buffer where save_screen() copied its data.

  In my fbcon
(http://platan.vc.cvut.cz/ftp/pub/linux/matrox-latest/matroxfb-2.6.7-c1784.
tar.gz) after I put

  origin = visual_origin = screenbuf;

below save_screen call, and removed clearing screen from radeon sources
both radeonfb and matroxfb were able to take over vgacon, without any
randomly colored characters on screen.
Petr, excellent detective work :-) .  I was suspecting vc_resize() was partly
causing the corruption, but never knew the reason until you pointed this
  It also allows for removing special fillrect clear, as now code
which clears upper few lines of logo area actually works...
Yes, I can now finally remove that ugly fillrect code.  I'll submit a patch on the
next batch of mm or BK release. 

Thanks.

Tony




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help