Re: [Linux-fbdev-devel] FB console clears with large white area

[Jim H. <jim...@ac...>]

On 29-Apr-2002 Sven wrote:
>> Except what actually happens is that most of the screen is cleared to white,
>> and console messages appear on the bottom line of the white area. As the
>> console scrolls the white area scrolls up the screen, though that part of it
>> to
>> the right of Tux remains as long as Tux remains.
> 
> I have the same problem with pm3fb.

Good. I have also had reports of this with a couple of other framebuffers, e.g.
Jani Monoses's tridentfb experience. So I don't think it is a problem with the
pm2/3 drivers.

I've not had much time to look further into this, but I think there are
actually two things going wrong. I need to find some more time. Here's what it
looks like to me at the moment.

First, in take_over_console(), save_screen() is called before the old console
is deinit()'ed. This calls vgacon_save_screen() to copy the console contents
at vc_origin into vc_screenbuf. Something is weird for me here; a little dumping
shows that vc_screenbuf always ends up filled with 0xffff.

Then take_over_console() closes the VGA console and calls visual_init() on the
FB console, which in turn calls fbcon_init() and fbcon_setup(). During
fbcon_setup(), the size of the new console is noted as being different from the
old console, and vc_resize() is called. This creates a new vc_screenbuf, and
fills it with data from the old size, taken from vc_origin. I think, though I'm
not sure, that at this point vc_origin is not yet updated for the FB and still
is the VGA origin. This data copied from vc_origin is again always 0xffff for
me.

So now I think I need to understand *why* the data at vc_origin for the VGA
console appears to be completely wrong.

> The difference is most probably that this is not broken for other drivers.
> Maybe the main reason of this, is that both pm2fb and pm3fb were first
> developped on plateforms without vga text console.

I suspect that all/most FB drivers (I think Jani works round it with
tridentfb) will show this problem. But to see it you need to be switching from
a VGA console to a FB console - if I remove the VGA console from my kernel
everything looks fine - so this problem will only practically be seen on PCs.
And there are not many reasons to use FB on a PC. 

> i don't know, but while writing the pm3 X driver, i noticed that may board
> will not save/restore the fonts correctly when doing MMIO (and when not doing
> MMIO it would not work in dual pm3 configuration) so we (Well Alan Hourihane
> actually) did change the code to read/save font memory using a special
> memcopy instead of resorting to the vga interface, which seemed broken in
> this respect. Maybe the pm2 chip shares this problem ?

That's interesting. I will compare your code to pm2fb.

> BTW, what exact pm2 chip are you using ?

My PCI reports TVP4020.

I have no documentation on the chip anyway, so I don't know how it is supposed
to work...

-- 
Jim Hague - jim...@in... (Work), ji...@be... (Play)
Never trust a computer you can't lift.