New libXvMC wrapper.
ajax at nwnk.net
Tue Sep 21 16:53:32 PDT 2004
On Tuesday 21 September 2004 19:32, Thomas Hellstrom wrote:
> 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.
This is why you don't use _init. Either mark the startup function as a
or create a startup function that the user has to call, or dlopen the right
lib dynamically at runtime (the way DRI does during glXCreateContext).
> 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.
Go ahead and do it the way you have it now, and extend the spec to cover this
cleanly in the future.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the xorg