New libXvMC wrapper.
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:
>>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.
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
Still, of course, there's the option to leave it out until a DRI-like
implementation is done.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xorg