configure check for Xrandr extension
When I originally submitted the patch to check for RandR during configuration, part of it looked like this:
+ AC_CHECK_HEADERS(X11/extensions/Xrandr.h, + [ dnl *** If X11/extensions/Xrandr.h exists... + AC_CHECK_LIB(Xrandr, XRRSetScreenConfigAndRate, + [ AC_DEFINE(HAVE_LIBXRANDR, 1, [Define if you have the Xrandr library]) + X_PRE_LIBS="$X_PRE_LIBS -lXrandr -lXrender" + ],, + $X_LIBS -lXext -lX11 -lXrender $X_EXTRA_LIBS + ) + ], + AC_MSG_WARN([[Xrandr extension not found, Wine will be built without it]]), + [#include <X11/Xlib.h>]) +
But the version that made it into CVS did not include the -lXrender. At least on my system, the check fails without that because the Xrandr library itself calls functions in Xrender. Is there a better way to specify that dependency or was this unintentional? Alex
Alex Pasadyn <ajp(a)mail.utexas.edu> writes:
But the version that made it into CVS did not include the -lXrender. At least on my system, the check fails without that because the Xrandr library itself calls functions in Xrender. Is there a better way to specify that dependency or was this unintentional?
My version of Xrandr doesn't need Xrender so I hoped it wouldn't be needed, guess I was wrong.... what does it need Xrender for? The problem with the dependency is that currently we deliberately don't link to libXrender but load it dynamically so that it works on all platforms; so I guess we'll need to load libXrandr dynamically too. -- Alexandre Julliard julliard(a)winehq.com
Alexandre Julliard wrote:
My version of Xrandr doesn't need Xrender so I hoped it wouldn't be needed, guess I was wrong.... what does it need Xrender for?
The problem with the dependency is that currently we deliberately don't link to libXrender but load it dynamically so that it works on all platforms; so I guess we'll need to load libXrandr dynamically too.
Without it, I get:
configure:7306: checking for XRRSetScreenConfigAndRate in -lXrandr configure:7337: gcc -o conftest -g -O2 -I/usr/X11R6/include conftest.c -lXrandr -L/usr/X11R6/lib -lXext -lX11 -lm >&5 /usr/X11R6/lib/libXrandr.so: undefined reference to `XRenderSetSubpixelOrder' collect2: ld returned 1 exit status configure:7340: $? = 1
I'm not really sure why that would be needed. What version are you using? Maybe I'm out of date? My system is RedHat 9 and I haven't done anything to upgrade the XFree86 (it's all version 4.3.0). Alex
Alex Pasadyn <ajp(a)mail.utexas.edu> writes:
I'm not really sure why that would be needed. What version are you using? Maybe I'm out of date? My system is RedHat 9 and I haven't done anything to upgrade the XFree86 (it's all version 4.3.0).
Actually it's my version that is too old, it's one from XFree86 4.2 and the Xrender call has been added after that, so it seems we don't have much choice. I'll put it back in the configure check for now, but we'll need to load libXrandr dynamically to fix this properly. -- Alexandre Julliard julliard(a)winehq.com
On October 16, 2003 12:02 am, Alexandre Julliard wrote:
Actually it's my version that is too old, it's one from XFree86 4.2 and the Xrender call has been added after that, so it seems we don't have much choice. I'll put it back in the configure check for now, but we'll need to load libXrandr dynamically to fix this properly.
Agreed. Also, once we have the dynamic check, we should drop the UseXRandR config option, and just use it unconditionally. Let's be lazy, and wait until someone comes with a good enough reason to disable it. BTW, any conceivable reasons for someone to disable it? If there is, it should be system wide, not Wine specific I'd think, no? -- Dimi.
On Thu, Oct 16, 2003 at 12:33:29AM -0400, Dimitrie O. Paun wrote:
Agreed. Also, once we have the dynamic check, we should drop the UseXRandR config option, and just use it unconditionally. Let's be lazy, and wait until someone comes with a good enough reason to disable it. BTW, any conceivable reasons for someone to disable it? If there is, it should be system wide, not Wine specific I'd think, no?
Dimi, when you are debugging a game and have your desktop change resolution all the time, trust me, you NEED a way to easily disable it. So, well, if you do not like the config file option, please AT LEAST put it as a registry key (I would hate to always have to change my Wine tree to disable it in the code itself). Lionel -- Lionel Ulmer - http://www.bbrox.org/
On Thu, 2003-10-16 at 07:53, Lionel Ulmer wrote:
Dimi, when you are debugging a game and have your desktop change resolution all the time, trust me, you NEED a way to easily disable it.
So, well, if you do not like the config file option, please AT LEAST put it as a registry key (I would hate to always have to change my Wine tree to disable it in the code itself).
Can't you use desktop mode for that?
On Thu, Oct 16, 2003 at 09:52:34AM +0100, Mike Hearn wrote:
On Thu, 2003-10-16 at 07:53, Lionel Ulmer wrote:
Dimi, when you are debugging a game and have your desktop change resolution all the time, trust me, you NEED a way to easily disable it.
So, well, if you do not like the config file option, please AT LEAST put it as a registry key (I would hate to always have to change my Wine tree to disable it in the code itself).
Can't you use desktop mode for that?
Well, and if the game starts a second process and you fall in the 'Desktop mode is buggy' problem :-) ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
On Thu, 16 Oct 2003, Lionel Ulmer wrote:
Well, and if the game starts a second process and you fall in the 'Desktop mode is buggy' problem :-) ?
OK, but in this case we should have it on by default, and it will not be exposed in winecfg, you'll need to use regedit/vim/emacs/etc. to control it. -- Dimi.
Dimitrie O. Paun wrote:
On Thu, 16 Oct 2003, Lionel Ulmer wrote:
Well, and if the game starts a second process and you fall in the 'Desktop mode is buggy' problem :-) ?
OK, but in this case we should have it on by default, and it will not be exposed in winecfg, you'll need to use regedit/vim/emacs/etc. to control it.
The only problem I had with desktop mode was the BadMatch errors with multiple processes, and those are gone now for all the cases where I saw them. Is there some other problem you had or are you still getting those errors? So yeah I personally think you should either let it change the resolutions or trap it inside a Wine desktop, and if there is a problem with desktop mode then we should fix it. Alex
On Thu, Oct 16, 2003 at 09:43:39AM -0500, Alex Pasadyn wrote:
The only problem I had with desktop mode was the BadMatch errors with multiple processes, and those are gone now for all the cases where I saw them. Is there some other problem you had or are you still getting those errors?
Yes. It's not BadMatches anymore, but another type of error. Will need to find which game does it o report the bug better.
So yeah I personally think you should either let it change the resolutions or trap it inside a Wine desktop, and if there is a problem with desktop mode then we should fix it.
As proper desktop support is a post-1.0 feature, I would really like to have a configuration option, even hidden somewhere :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Lionel Ulmer wrote:
As proper desktop support is a post-1.0 feature, I would really like to have a configuration option, even hidden somewhere :-)
Well it currently does enable RandR based on the option. And for everything I tested desktop mode worked fine for trapping the app inside. I was hoping that whatever bug you're getting in desktop mode didn't require the eventual big changes to fix it. But anyway, if you do turn everything off including desktop mode, you will probably want to hack X11DRV_Settings_Init in your tree to return additional modes for the "NoRes" case by adding some calls to X11DRV_Settings_AddOneMode. Otherwise you only get one mode that is the same size as the X desktop. Alex
participants (6)
-
Alex Pasadyn -
Alexandre Julliard -
Dimitrie O. Paun -
Dimitrie O. Paun -
Lionel Ulmer -
Mike Hearn