Re: [Linux-fbdev-devel] API prototype doc

[Sven <lu...@dp...>]

On Tue, Dec 04, 2001 at 09:15:01AM -0800, Sottek, Matthew J wrote:
> 
> >>The only reason to not allow mmap is that it is hard to force apps
> >>to stop writing when they shouldn't.
> 
> >Why to stop them? If we do not provide full virtualization for them,
> >we should not put any additional policy on their behavior.
>  
> I'm ok with leaving out policy, but the problem is that we have no
> way to notify the client in a timely manner either. They would
> have to poll the surface to look at the status.
> 
> So what should be done on a vt switch?
> I think it may be ok to zap() someone's mmap during a vt switch but
> otherwise make them work out their own policy. vt switches are
> slow anyway.
> 
> I am unsure of how XFree handles this. Does the X server trap the
> vt switch sequence, call leave_vt() then switch the vt?

Well, X handles it in two ways :

1) X is not fbdev aware ...

  => it simply use vesa to save the text screen status and content, and hopes
     that fbdev did save the data before.

  (notice, on the glint driver is not fbdev aware for boards other than pm2
   one, but X cohabits nicely with pm3fb in this way)

2) X is fbdev aware, and using fbdevhw.

  => again, fbdev is supposed to save its stuff when leaving the vt.

When leaving X again, it is Xs turn to save it's stuff.

Some syncing is involved, which slows down things.

Friendly,

Sven Luther