New libXvMC wrapper.

Adam Jackson 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 
constructor:

http://gcc.gnu.org/onlinedocs/gcc-3.4.2/gcc/Function-Attributes.html#Function-Attributes

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

Go ahead and do it the way you have it now, and extend the spec to cover this 
cleanly in the future.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20040921/b8ae7189/attachment.pgp>


More information about the xorg mailing list