Xserver doesn't support XvPutImage to Pixmap?

[Matthew Fincham]

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...

Matthew