Xserver doesn't support XvPutImage to Pixmap?

[Michel Dänzer]

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