[Linux-fbdev-devel] Re: fbdev, console, (video) overlay/underlay & fbtv

[Romain D. <do...@ir...>]

Gerd Knorr wrote:

> > I had a hacked pm3fb with 8+24 overlay (not video overlay),
> > with fbcon in the upper 8 bits (CI8) and a 24 bits underlay. `fbi'
> > did simply put the picture in the lower 24 bits, anc after a C-c
> > the image would stay as an underlay in the console.
>             ^^^^^^^^^^
> Tried that?

Yes, it did in the special 8+24 overlay mode (I don't remember
trying in regular 24/32 bpp). Gave me a nice Debian underlay
background. Too bad most of the logo is the same color than
the fbcon text :-)

> fb applications have to take care about virtual consoles.  They
> need to know if they running on the foreground vt or not (i.e.
> if they can draw to the framebuffer or not).

What happen if there's _no_ VT on the FB ?

> If you switch away from the X-Server to a text console you probably
> don't want the X-Server continue updating the screen because that
> would f*ck up your terminal.

Yes, that's a problem. Another thing I didn't try: what happen
if you display a picture on FB1 from a VT0 on FB0, and switch
to VT1 on FB0. The picture should not be erased on FB1, yes ?
I'll need to try that.

> It is still not clear what is supported to happen to any overlays if the
> user switches to another virtual console.  Will this invalidate any
> existing overlays?  Note that your fbcon virtual consoles might have
> another video mode / color depth / font / ... each, which might also
> affect the capabilities of the hardware (ati rage 3d can do yuv overlays
> in 16 bpp and more only, but not in 8 bpp ...)

My personal belief is that any app should display on the
FB if there's no VT or if it is the active VT ; and that
upon switching active VT or video mode all state should
be assumed lost, i.e. memory buffer are invalid and all
overlay are disabled.

Say, what happen if a user switch video mode for a VT
from another terminal ? (good old telnet :-) Another
thing I didn't try yet...

> How the overlay memory area can be freed?

w/ _FREEBUF :-)

> Will the STOP ioctl do that too?

Nope, not any longer. An app might want to store picture in 2 or more
buffer and start/stop overlay from either one without redisplaying
the picture every time.

> Ahem.  That's a non-trivial problem.

We wouldn't discuss the subject if it was trivial, would we ? :-)

> qt-embedded can do that I think (have some window management
> in place for multiple apps sharing a framebuffer display).

Sven suggested a problem with mmap() ; can 2 apps
mmap() the framebuffer simultaneously ? If not, then
there's no need for inter-app resources control. If
yes...

> -- 
> Damn lot people confuse usability and eye-candy.

I do :-)

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian