* Finally found why 2.6.x has troubles with taking over vgacon
@ 2004-07-03 19:56 Petr Vandrovec
2004-07-04 0:58 ` Antonino A. Daplas
0 siblings, 1 reply; 2+ messages in thread
From: Petr Vandrovec @ 2004-07-03 19:56 UTC (permalink / raw)
To: adaplas; +Cc: linux-fbdev-devel
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Finally found why 2.6.x has troubles with taking over vgacon
2004-07-03 19:56 Finally found why 2.6.x has troubles with taking over vgacon Petr Vandrovec
@ 2004-07-04 0:58 ` Antonino A. Daplas
0 siblings, 0 replies; 2+ messages in thread
From: Antonino A. Daplas @ 2004-07-04 0:58 UTC (permalink / raw)
To: Petr Vandrovec; +Cc: linux-fbdev-devel
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2004-07-04 0:57 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-07-03 19:56 Finally found why 2.6.x has troubles with taking over vgacon Petr Vandrovec
2004-07-04 0:58 ` Antonino A. Daplas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).