<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body text="#000000" bgcolor="#ffffff"> Adam Jackson wrote: <blockquote type="cite" cite="mid200409211854.39949.ajax@nwnk.net"> <pre wrap="">On Tuesday 21 September 2004 18:34, Thomas Hellstrom wrote: </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> Why do you need -nostartfiles? </pre> </blockquote> 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. <blockquote type="cite" cite="mid200409211854.39949.ajax@nwnk.net"> <pre wrap=""> 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 </pre> </blockquote> 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 </body> </html>