DirectFB - Home of the pragmatist Roadmap

[directfb-users] Re: DirectFB persistent video output vs exclusive acces
Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[directfb-users] Re: DirectFB persistent video output vs exclusive access

On Wed, Jul 07, 2004 at 10:35:01PM +0100, James Gatt wrote:
> Hi,
> Firstly I should apologise in case this is not fully relevant to 
> directfb itself - the solution to the problem I have might as likely be 
> in mplayer as directfb.
> I am writing a media server type of application that is to be used with 
> a remote control and television / AV system. Nothing else - no keyboard, 
> mouse etc. (A keyboard might get added later, but the point is it is not 
> required to use the system.)  Anyway, this means the entire user 
> interface always uses the television - either it displays the user 
> interface, or the output of mplayer (and later maybe other things such 
> as xmame).
> The graphics card is a Matrox G450, and I am using the dfbmga driver in 
> mplayer.
> The problem comes when switching between the user interface and mplayer 
> - as far as I can tell, the user interface must give up the display so 
> that mplayer can get exclusive access to it. This causes a glitch on the 
> video output which upsets the television. I think the signal actually 
> disappears briefly.

It does.

> Is there a technical reason why it is necessary for 
> the display to be altered when an application exits?

The new app will be re-initializing the TV encoder to pretty much the same 
settings so in that case the re-init might not be strictly necessary.

The problem is really in the driver. The driver only knows about what are 
called regions. Only one region can be active at any time. When the 
fullscreen app starts/stops the previous region will get removed from the 
driver and after that the new one added. When a region is removed the 
driver disables the output and it doesn't know if the output will get 
re-enabled later.

I think the solution for this problem might actually come from the (still 
unfinished) screen API. Much of the TV encoder stuff should actually be 
handled by the screen code. If turning the TV encoder on/off would be 
handled by the screen code the re-init might not have to happen.

Ville Syrjälä

Home | Main Index | Thread Index / Development / Old Archives