[vlc-devel] RE : [PATCH] -- skins2: workaround to possible hangingswith xlib

brezhoneg1 brezhoneg1 at yahoo.fr
Sun May 24 23:07:03 CEST 2009



> -----Message d'origine-----
> De : vlc-devel-bounces at videolan.org [mailto:vlc-devel-
> bounces at videolan.org] De la part de Rémi Denis-Courmont
> Envoyé : dimanche 24 mai 2009 21:55
> À : vlc-devel at videolan.org
> Objet : Re: [vlc-devel] [PATCH] -- skins2: workaround to possible
> hangingswith xlib
> 
> Le dimanche 24 mai 2009 22:33:32 brezhoneg1, vous avez écrit :
> > - Unlike Ubuntu7.10, skins2 very often (but not always) hangs when
> > starting a new input. An expected MapNotify event fails to occur. In
the
> > attached patch, a counter has been added to get out of an infinite
loop
> > in case this happens. This (rather ugly) workaround makes it
possible to
> > use skins2 on Debian quite satisfactorily. In the long run,
rewriting
> > skins2 with xcb could be a good thing as X11 is really a whimsical
thing
> > in a multi-threaded context.
> 
> Using the XCB video output might just work around the problem, as
skins2
> should then be the only Xlib user.
> 

I just tested on Debian5.0 => vlc -I skins --vout xcb-xv
The problem still exists.

Actually, there are still three xlib threads :
          - the skins2 thread (skins2 interface)
          - the qt4 thread (for dialogs)
          - the vout thread when requesting a window handle(since it is
the thread executing code provided by skins2 as a window provider)

As it is coded today, skins2 as a window provider creates a new window
whenever an incoming vout request is received. Maybe, creating a pool of
windows at initialization time would made things less painful for xlib
(the vout thread would then just reuse pre-existing handles) but also a
bit more complicated to manage.


Erwan10








More information about the vlc-devel mailing list