[vlc-devel] RE : RE : skins2 update

[brezhoneg1]

Hi,

> -----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é : vendredi 19 février 2010 17:44
> À : Mailing list for VLC media player developers
> Objet : Re: [vlc-devel] RE : skins2 update
> Importance : Faible
> 
> 
> 
> On Mon, 15 Feb 2010 15:06:18 +0100, "brezhoneg1" <brezhoneg1 at yahoo.fr>
> wrote:
> > - Linux port
> >   Linux port was not functioning satisfactorily in vlc1.0 (frequent 
> > deadlocks due to how xlib was used)
> >   This part has been rewritten, and vlc1.1 is performing on 
> Linux as 
> > fine as it does on Windows.
> 
> Hmm, you mean the X11 port now uses XLockDisplay() ? But are 
> we sure that
> XInitThreads() is called early enough - especially before the 
> Qt4 (or GLX or PulseAudio*) plugin start using Xlib?
> 
> * PulseAudio uses Xlib (to find which pulse daemon to use for 
> the X session).

You're right and that is also true for qt4 as interface.

Yet,likehood is that in vlc1.1, skins2 should issue the
first xlib call (which is XInitThreads). (qt4 is launched by skins2,
glx and pulseAudio are used as the result of an input)

What I meant is that skins2 now does things the way qt4 has
been doing with success, i.e never issue xlib calls directly
in callbacks, but rather post asynchronous thread-safe messages

After a lot of testing, I can assure skins2(vlc1.1) on Debian5.0 
doesn't show any more problem wrt xlib as vlc1.0 did.
(I also tested with glx, but not pulseAudio)

In the long run, fully rewritting the xlib part of skins2 with xcb is
probably desirable.

Regards
Erwan10