Stefan Dösinger wrote:
Hi,
boils down to a one-line patch. RTLD_NEXT doesn't work, I have to use
RTLD_DEFAULT to make wine (or the dynamic loader) use my functions.
You should send patches to [EMAIL PROTECTED] to get them included.
Thanks. Once I have my local git copy I'll try to create t
Hi,
> boils down to a one-line patch. RTLD_NEXT doesn't work, I have to use
> RTLD_DEFAULT to make wine (or the dynamic loader) use my functions.
You should send patches to [EMAIL PROTECTED] to get them included.
Stefan
Mike McCormack wrote:
eg. use RTLD_NEXT instead of the real libGL handle. This would make it
possible to preload my own library but wouldn't change the weak
linking. In fact, that's how I've modified my local wine copy, and it
worked.
Well, you have the patch now, so all you need to do is
eg. use RTLD_NEXT instead of the real libGL handle. This would make it
possible to preload my own library but wouldn't change the weak linking.
In fact, that's how I've modified my local wine copy, and it worked.
Well, you have the patch now, so all you need to do is submit it ;)
Mike
Mike McCormack wrote:
Mike Hearn wrote:
On Thu, 01 Dec 2005 16:12:47 +, Tomas Carnecky wrote:
I've had a discussion with someone through this list about wine and
libGL.so. It was about wine using dlopen("libGL.so") instead of linking
directly with libGL.so.
IIRC this was done so Code
Mike Hearn wrote:
On Thu, 01 Dec 2005 16:12:47 +, Tomas Carnecky wrote:
I've had a discussion with someone through this list about wine and
libGL.so. It was about wine using dlopen("libGL.so") instead of linking
directly with libGL.so.
IIRC this was done so CodeWeavers can ship a GL ena
On Thu, 01 Dec 2005 16:12:47 +, Tomas Carnecky wrote:
> I've had a discussion with someone through this list about wine and
> libGL.so. It was about wine using dlopen("libGL.so") instead of linking
> directly with libGL.so.
IIRC this was done so CodeWeavers can ship a GL enabled build. I don'
Stefan Dösinger wrote:
How is the nvidia driver doing recently? Does it have acpi suspend support?
Can't comment, because my computer is a desktop computer, not a laptop
and I havent tried suspend or sleep (I don't even know how to configure it).
How is the speed compared to the Windows dri
Stefan Dösinger wrote:
How is the nvidia driver doing recently? Does it have acpi suspend support?
Seems like ACPI suspend isn't supported under amd64 :(
$ cat /sys/power/state
standby mem
> My approach is:
> ...
I can't comment on the technical details, because I am not an OpenGL expert at
all. But I'd like to test it when you're finished.
There may be a workaround for the glReadPixels slowlyness. I've seen that both
mplayer and xine can draw a 2D movie fast onto an OpenGL texture
Stefan Dösinger wrote:
* The fglrx driver: glReadPixels, glWritePixels, glTexImage2D and friends are
_terribly_ slow with this driver( 1 fps when accessing the back buffer). Just
follow the Direct3D discussions or search the archives, this problem has been
discussed before, and it will come up
Stefan Dösinger wrote:
I want to create fraps for linux. Using XShmGetImage() and friends is
too slow. So my first
approach was to create a fullscreen opengl app and do glReadPixels().
But this performs
very badly when there are two opengl applications running at the same
time (fps drops from
Stefan Dösinger wrote:
Why do you want to hook GL functions? I consider this a hacky workaround for
bugs which should be fixed otherwise, but I might be wrong with this. The
only thing I know is a workaround for the fglrx driver, but for Wine, this
was fixed elsewhere.
I want to create fr
> I want to create fraps for linux. Using XShmGetImage() and friends is
> too slow. So my first
> approach was to create a fullscreen opengl app and do glReadPixels().
> But this performs
> very badly when there are two opengl applications running at the same
> time (fps drops from
> Now what are
> There is absolutely no reason not to link with libGL.so directly:
> Even if you make OpenGL a hard dependency, nothing will break. Just
> announce it well so that everybody understands the change and make
> --disable-opengl the default
> option. Now everyone can get wine and it will work out-of-t
I've had a discussion with someone through this list about wine and
libGL.so. It was
about wine using dlopen("libGL.so") instead of linking directly with
libGL.so.
I still don't understand why the wine developers have made this
decision. I'm again at
the point where I need to hook OpenGL (glX)
16 matches
Mail list logo
