Redirected XV (proposed API change)

[Aaron Plattner]

Roland Scheidegger wrote:
> Aaron Plattner wrote:
> 
>> Since we're changing the ABI/API for 7.1, I figured now is a good time
>> to add
>> redirected XV support to the DDX.  The proposed patch is here:
>>
>>   http://people.freedesktop.org/~aplattner/xv-redirection-1.patch
>>
>> The change adds a DrawablePtr parameter to the XV driver hooks
>> responsible for XV
>> rendering.  Since this is an API change, I want to get feedback from
>> this list
>> before checking it in.  What do you guys think?
>>
>> A simple proof-of-concept implementation for the nv driver is here:
>>
>>    http://people.freedesktop.org/~aplattner/nv-xv-redirection-1.patch
>>
>> It only works for windows with backing pixmaps in VRAM.
> 
> 
> May I ask what purpose this change serves? Could you use this to use the
> hw scaler with Xgl (i.e. without needing a fragment program and/or yuv
> texture extension), by rendering the overlay to offscreen area and using
> that as a texture?
> Note though that not all hardware will allow this, if you want to use
> the hw overlay (radeons won't, for instance, haven't looked at other
> drivers), of course you can always use a sw fallback.

This change is designed to allow X.org drivers to provide redirected XV support,
e.g. for running mplayer with xcompmgr.  Currently, the DDX provides the driver
no indication that the target window is redirected.  As you suggest, Xgl could
probably use redirected windows on its parent server to provide XV acceleration,
although it seems like proper XV pixmap support would be better for that.

Now that you mention it, that might be a better approach: add a new
PutImagePixmap function pointer to the AdaptorRec and have xf86XVPutImage call
that when its pDraw argument is a pixmap or redirected window.  This would have
the advantage of allowing drivers to expose blit or texture adaptors supporting
pixmap and redirected window rendering, while also exposing an overlay adaptor
that only works for unredirected windows.  The downside to that is that people
will have to explicitly request the right port in their apps.

-- Aaron