On Wed, 2010-02-17 at 08:13 +0200, Matthew Fincham wrote: > On 17-02-10 07:57, Matthew Fincham wrote: > > On 16-02-10 17:27, Michel Dänzer wrote: > > > >> On Tue, 2010-02-16 at 14:17 +0200, Matthew Fincham wrote: > >> > >> > >>> On 16-02-10 11:29, Michel Dänzer wrote: > >>> > >>> > >>>> On Tue, 2010-02-16 at 10:39 +0200, Matthew Fincham wrote: > >>>> > >>>> > >>>> > >>>>> Currently I am using XvPutImage to display a video stream. The video > >>>>> needs to be overlayed with various items (pixmaps, text, custom > >>>>> drawing). As it stands there is a lot of flickering of the overlayed > >>>>> items. When this is double-buffered (using standard pixmaps) the > >>>>> flickering, obviously, goes away. > >>>>> > >>>>> I see that XVPutImage does not support writing to pixmaps, only to > >>>>> windows (xf86XVEnlistPortInWindow seems to be the start of the > >>>>> problem...). The system is running version 1.3.0. I have checked 1.7.1 > >>>>> and seen that it too doesn't support XVPutImage to pixmaps. > >>>>> > >>>>> I have a few questions: > >>>>> > >>>>> - has any progress been made in supporting XVPutImage with pixmaps? > >>>>> > >>>>> > >>>>> > >>>> Somewhat: > >>>> > >>>> http://bugs.freedesktop.org/show_bug.cgi?id=2114 > >>>> > >>>> > >>> Hi Michel > >>> > >>> Thanks for the link. I have applied the patch (from Kusanagi Kouichi) > >>> but only managed to crash the X server when writing to a pixmap. I > >>> recompiled Xorg, the (Intel) drivers and the app using drawing the Xv > >>> image. > >>> > >>> Afetr applying the patch should I expect to be able to write to pixmaps, > >>> or have I done something wrong (left out a recompile or something else)! > >>> > >>> > >> As I mentioned in http://bugs.freedesktop.org/show_bug.cgi?id=21143#c7 > >> the patch as it stands breaks the video driver ABI, so the video driver > >> needs to be rebuilt against the patched xserver. If that wasn't the > >> problem, please provide a backtrace of the crash. > >> > >> > >> > >> > > This is the backtrace, although I am not 100% confident of it. Certainly > > the references to qt4 are wrong. I'll see if I can get more info. > > > > Core was generated by `Xorg'. > > Program terminated with signal 6, Aborted. > > #0 0xbba1a22f in kill () from /usr/pkg/qt4/lib/libc.so.12 > > (gdb) bt > > #0 0xbba1a22f in kill () from /usr/pkg/qt4/lib/libc.so.12 > > #1 0xbbab6340 in abort () from /usr/pkg/qt4/lib/libc.so.12 > > #2 0x0809ad6e in ddxGiveUp () > > #3 0x0819a3b7 in AbortServer () > > #4 0x0819a83f in FatalError () > > #5 0x080b6d0c in xf86SigHandler () > > #6<signal handler called> > > #7 0x0000001f in ?? () > > > > Many thanks > > Matthew > > > > > > > From line 1749 in hw/xfree86/common/xf86xv.c (the xf86XVPutImage function): > > /* If we are changing windows, unregister our port in the old window */ > if(portPriv->pDraw&& (portPriv->pDraw != pDraw)) > xf86XVRemovePortFromWindow((WindowPtr)(portPriv->pDraw), portPriv); > > /* Register our port with the new window */ > ret = xf86XVEnlistPortInWindow((WindowPtr)pDraw, portPriv); > if(ret != Success) goto PUT_IMAGE_BAILOUT; > > if(!REGION_NOTEMPTY(pScreen,&ClipRegion)) { > clippedAway = TRUE; > goto PUT_IMAGE_BAILOUT; > } > > > If a return is done before xf86XVEnlistPortInWindow X does not crash. If > a return is done after xf86XVEnlistPortInWindow X crashes. Rather crude > debugging, I know. Now I don't know the X code at all, but I see that > the xf86XVEnlistPortInWindow casts the drawable to a WindowPtr. I > presume this will cause problems if the drawable is in fact a pixmap...
Right, that code only makes sense if the drawable actually is a window. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
