Re: [Linux-fbdev-devel] 2 pm3fb questions/problesm ...

[Petr V. <VAN...@vc...>]

On 19 Jun 01 at 18:09, Romain Dolbeau wrote:
> Petr Vandrovec wrote:
> > And this is what? Do you mean that vgacon -> pm3fb switch during
> > bootup does not preserve contents of screen? Make sure that
> > on enter to register_framebuffer() pm3fb is in VGA mode, memory
> > is mapped at 0xB8000 and SEQ/GDC/CRTC are set for VGA text mode.
> 
> It definitely isn't. I don't even know what VGA mode is, and I
> have absolutely no intention to ever learn. VGA is one of the
> crappy thing that keep me away from x86 hardware.

So you should not have garbage problem on your machine.
 
> > and all code which changes memory layout and enables/disables VGA emulation
> > should be executed only from inside yourfb_set_var and not before
> > call to register_framebuffer.
> 
> I'm far off the mark :-) I've ripped-off pm2fb for pm3fb, so
> there's _set_var before the register_frambuffer. That's
> also the way it's done in skeletonfb...

Then you cannot take over vgacon...
 
> Also, pm3fb depend on fbgen, which supplies the _set_var
> and _get_var, and currcon. I have no control over those.
> 
> So, is there any way to prevent vgacon to try to force is
> way inside the memory that rightfully belong to pm3fb ? :-)
> That way, there would be neither previous content nor
> garbage...

Only thing you can do is read read first and last console from
video=vc: kernel parameter, and then at the beginning of your
code you can call con_save_screen for all these terminals you
are taking over. Then replace console's con_save_screen handler 
with NULL. But it is very dangerous, incompatible and so on...
It is much better just restore GDC/SEQ/CRTC state (you need
to restore only registers needed for proper reading characters
from videoram, ~10 registers) to their values on enter to your 
driver just before you do call to register_framebuffer().
                                            Best regards,
                                                Petr Vandrovec
                                                van...@vc...