New libXvMC wrapper.

Thomas Hellstrom unichrome at shipmail.org
Tue Sep 21 16:32:58 PDT 2004


Adam Jackson wrote:

>On Tuesday 21 September 2004 18:34, Thomas Hellstrom wrote:
>  
>
>>Hi, list!
>>
>>Anybody opposed to this going in it's current form? If not, it will be
>>enabled for linux and gcc, where I know the -nostartfiles option will work.
>>    
>>
>
>Why do you need -nostartfiles?
>  
>
There's an _init() function in the wrapper, dlopening the right lib. 
Without this option, a conflicting _init() function will
be linked with the library.

>As mentioned earlier, the XvMC protocol really should ask the server for the 
>name of the client driver to load, the way DRI does.  But this is certainly 
>better than requiring every XvMC client to know about every possible driver.
>
>- ajax
>  
>
I agree. This is a temporary solution, and it is possible to implement 
an XGetXvMCDriverName() function and protocol which is called by the 
XvMC client lib as part of  XvMCCreateContext(), without the player 
client having to know about it, thus maintaining binary compatibility on 
the client side. The problem is on the X server side:

With NVIDIA's closed source being the, by far, most used XvMC client lib 
I thought the prospect of having them implement the above function in 
their DDX would be quite small, which would mean the wrapper would still 
have to have a default fallback behaviour to load a suitable driver if 
the XGetXvMCDriverName() function fails. This is a start, to satisfy an 
immediate need.

Still, of course, there's the option to leave it out until a DRI-like 
implementation is done.

Opinions?

/Thomas





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20040922/eeb1b56d/attachment.html>


More information about the xorg mailing list