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 hop
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?
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/em
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
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 c
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
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 conceiva
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 libXrand
Alex Pasadyn <[EMAIL PROTECTED]> 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
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 platf
Alex Pasadyn <[EMAIL PROTECTED]> 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 unin
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,
+
12 matches
Mail list logo