From: Antonino D. <ad...@po...> - 2002-04-30 18:57:42
|
> > As far as I can tell at the moment, in take_over_console the outgoing console > is suppose to save its screen contents (if visible) and these will be put onto > the new console when update_screen() is called. Dumping the saved VGA screen, > it seems that the saved screen consists entirely of 0x720, which I think > explains the white. Why the VGA screen contents are like that I have, as yet, no > idea. > If I remember PC text mode correctly, 0x720 is the correct code for space. 7 is the attribute (I forgot what it stands for though - probably normal) and 20 is just the ASCII code for space. So, the console essentially blanked your screen, but is misinterpreted when switched to graphics mode. Tony |
From: Jim H. <jim...@ac...> - 2002-04-30 20:56:57
|
On 30-Apr-2002 Antonino Daplas wrote: >> As far as I can tell at the moment, in take_over_console the outgoing >> console >> is suppose to save its screen contents (if visible) and these will be put >> onto >> the new console when update_screen() is called. Dumping the saved VGA >> screen, >> it seems that the saved screen consists entirely of 0x720, which I think >> explains the white. Why the VGA screen contents are like that I have, as >> yet, no >> idea. >> > If I remember PC text mode correctly, 0x720 is the correct code for > space. 7 is the attribute (I forgot what it stands for though - > probably normal) and 20 is just the ASCII code for space. So, the > console essentially blanked your screen, but is misinterpreted when > switched to graphics mode. Sorry, I got that detail wrong in the original message. The 0x720s are what is in vc_screenbuf *before* calling save_screen(). save_screen() produces 0xffff (for me on pm2fb), which I am sure is responsible for the white rectangle I see. -- Jim Hague - jim...@in... (Work), ji...@be... (Play) Never trust a computer you can't lift or you don't control. |