XVidMode is required for Gamma Control
I've found that XVidMode is required for gamma control, and that it defaults to off. There are two bug reports about gamma. One is Diablo 2 as it fails to run at all in D3D mode because of it (and with a cryptic error too). The other is the gamma slider fails to produce the effect. There are three ways to fix the problem: 1) Allow XVidMode to init for gamma control regardless the setting of UseXVidMode. I already sent a patch for this. 2) Make UseXVidMode default to "Y". 3) Tell people to set UseXVidMode manually. Let me know what any of you think is best. I'd prefer the first one so that I won't have people scratching their heads over what is going on. Though #2 might be more correct than #1. Something should be changed because it's silly that Diablo 2 cannot run by default. Jesse
"Jesse Allen" <the3dfxdude(a)gmail.com> writes:
There are three ways to fix the problem: 1) Allow XVidMode to init for gamma control regardless the setting of UseXVidMode. I already sent a patch for this.
2) Make UseXVidMode default to "Y".
3) Tell people to set UseXVidMode manually.
Let me know what any of you think is best. I'd prefer the first one so that I won't have people scratching their heads over what is going on. Though #2 might be more correct than #1. Something should be changed because it's silly that Diablo 2 cannot run by default.
We should probably do both #1 and #2. I don't think there's any reason to have it disabled by default. -- Alexandre Julliard julliard(a)winehq.org
1) Allow XVidMode to init for gamma control regardless the setting of UseXVidMode. I already sent a patch for this.
2) Make UseXVidMode default to "Y".
Let me know what any of you think is best. I'd prefer the first one so that I won't have people scratching their heads over what is going on. Though #2 might be more correct than #1. Something should be changed because it's silly that Diablo 2 cannot run by default.
We should probably do both #1 and #2. I don't think there's any reason to have it disabled by default. Hm. How does that interact with XRandr? There are still mouse grab issues in some games(half-life comes to mind), often because games do not care to grab the mouse. In this case using XVidMode will cause the mouse to leave the window, which is really disturbing.
But if XRandr will still be used for screen resolution setup, than this is fine. Stefan
On 4/4/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
1) Allow XVidMode to init for gamma control regardless the setting of UseXVidMode. I already sent a patch for this.
2) Make UseXVidMode default to "Y".
Let me know what any of you think is best. I'd prefer the first one so that I won't have people scratching their heads over what is going on. Though #2 might be more correct than #1. Something should be changed because it's silly that Diablo 2 cannot run by default.
We should probably do both #1 and #2. I don't think there's any reason to have it disabled by default. Hm. How does that interact with XRandr? There are still mouse grab issues in some games(half-life comes to mind), often because games do not care to grab the mouse. In this case using XVidMode will cause the mouse to leave the window, which is really disturbing.
But if XRandr will still be used for screen resolution setup, than this is fine.
Stefan
I haven't had a mouse leave the window in a long time.. Probably because I use DXGrab (unless that has been deprecated)... Tom
On 4/4/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Hm. How does that interact with XRandr? There are still mouse grab issues in
I believe that XRandR is preferred in the current code.
some games(half-life comes to mind), often because games do not care to grab the mouse. In this case using XVidMode will cause the mouse to leave the window, which is really disturbing.
Is this with a virtual desktop or fullscreen with larger virtual resolution?
On 4/4/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Hm. How does that interact with XRandr? There are still mouse grab issues in some games(half-life comes to mind), often because games do not care to grab the mouse. In this case using XVidMode will cause the mouse to leave the window, which is really disturbing.
But if XRandr will still be used for screen resolution setup, than this is fine.
Ok, this is what I figured out: Under these conditions: Full screen game No virtual desktop DXGrab = Y UseXRandR = Y UseXVidMode = Y 1024x768 res, 1280x1024 virtual res The mouse cursor stays in window. XRandR seems preferred over XVidMode for managing res. Under these conditions: Full screen game No virtual desktop DXGrab = Y UseXRandR = N UseXVidMode = Y 1024x768 res, 1280x1024 virtual res The mouse cursor doesn't stay in the window. XVidMode is used in this case. I hope these are acceptible results. These are with my patch applied of course. I didn't try without DXGrab. I dunno if it's deprecated or not. Jesse
Hi,
I hope these are acceptible results. These are with my patch applied of course. I didn't try without DXGrab. I dunno if it's deprecated or not. Yes, they are fine.
Of course we might want to fix the mouse code sometimes to make the mouse stay insinde the virtual desktop or the window with XVidMode at all times if that's possible at all. It's pretty annoying that KDE re-aranges all windows and icons when a game sets the screen res to 640x480. Stefan
that's possible at all. It's pretty annoying that KDE re-aranges all windows and icons when a game sets the screen res to 640x480.
Yes, this is pretty annoying. Windows end up becoming fullscreen after the switch to 640x480 and when the res switches back to 1680x1050 the windows apparently scale with the resolution change so everything stays full screen. Chris
On Tue, Apr 04, 2006 at 09:17:24PM +0200, Stefan Dösinger wrote:
Of course we might want to fix the mouse code sometimes to make the mouse stay insinde the virtual desktop or the window with XVidMode at all times if that's possible at all.
I tried once to do a 'DXGrab' for the virtual desktop but was constrained by the fact that only the connection doing the mouse grab would get any subsequent events. And as in Wine you can have multiple processes sharing the same window, only the one doing the grab would get events and all other processes won't get any mouse / keyboard inputs. Now with the new explorer and all that, maybe one could imagine it forwarding the events to other applications via the server, but well, this is a part of Wine I do not master at all :-) Lionel PS: 'non-exclusive grab' was one of my 'X11' extension I planned to work one day :-) -- Lionel Ulmer - http://www.bbrox.org/
On 4/4/06, Alexandre Julliard <julliard(a)winehq.org> wrote:
"Jesse Allen" <the3dfxdude(a)gmail.com> writes:
2) Make UseXVidMode default to "Y".
We should probably do both #1 and #2. I don't think there's any reason to have it disabled by default.
I think it used to default to Y until the switch-over to the registry, and the setting got lost. The setting was created I believe back in 2000 when someone said that XVidMode was crashing for him so he wanted a way to disable it. XRandR defaults to Y too now and it is preferred over XVidMode in the current code in video resolution setting so leaving it N is ok I think as long as gamma is supported. Jesse
Jesse Allen wrote:
I think it used to default to Y until the switch-over to the registry, and the setting got lost.
Perhaps that's why Starcraft suddenly started becoming playable? You use the mouse to scroll the play area in Starcraft, it's completely broken unless the mouse stays within the window. Used to be broken a year ago or so, works dandy now. If you change this, ping me and I'll test Starcraft?
On 4/4/06, Molle Bestefich <molle.bestefich(a)gmail.com> wrote:
Jesse Allen wrote:
I think it used to default to Y until the switch-over to the registry, and the setting got lost.
Perhaps that's why Starcraft suddenly started becoming playable?
You use the mouse to scroll the play area in Starcraft, it's completely broken unless the mouse stays within the window. Used to be broken a year ago or so, works dandy now.
If you change this, ping me and I'll test Starcraft?
Just set UseXVidMode = Y in HKCU\Software\Wine\X11 Driver and test the game. If people have problems with it defaulting to Y, then we can leave it N, but still have the first patch and fix the no gamma control problem. This patch is attached here so anyone else can look at it. I don't believe this patch will cause any problem. Jesse
Jesse Allen wrote:
Just set UseXVidMode = Y in HKCU\Software\Wine\X11 Driver and test the game.
Ah, crap, someone's broken it completely. Can't exactly blame UseXVidMode though. It's something that happened after upgrading to 0.9.10. It doesn't switch to fullscreen anymore. Mouse grabbing is now broken both with and without UseXVidMode. *Sigh*. Matt Finnicum wrote:
Starcraft's been working very well for me for much longer than that.
If you don't pull source via GIT/CVS/SVN, compile/install and nuke your ~/.wine on a regular basis, you don't count :-).
Molle Bestefich wrote:
Mouse grabbing is now broken both with and without UseXVidMode.
Scratch that. When using a virtual desktop, DXGrab works fine, with UseXVidMode=Y too. It does screw up if the window is placed near the KDE taskbar and you drag the mouse in that direction, but alas..
On Tue, Apr 04, 2006 at 10:42:18AM -0700, Jesse Allen wrote:
1) Allow XVidMode to init for gamma control regardless the setting of UseXVidMode. I already sent a patch for this.
2) Make UseXVidMode default to "Y".
3) Tell people to set UseXVidMode manually.
4) do not return an error message if gamma is not supported :-) For me Gamma is a 'nice to have' but like some stubs, the game would work almost as well if we just ignore the call... So instead to forward the error to the application, why should we not put a nice ERR message on the console and just ignore the gamma change and return OK ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
On 4/4/06, Lionel Ulmer <lionel.ulmer(a)free.fr> wrote:
On Tue, Apr 04, 2006 at 10:42:18AM -0700, Jesse Allen wrote:
1) Allow XVidMode to init for gamma control regardless the setting of UseXVidMode. I already sent a patch for this.
2) Make UseXVidMode default to "Y".
3) Tell people to set UseXVidMode manually.
4) do not return an error message if gamma is not supported :-)
For me Gamma is a 'nice to have' but like some stubs, the game would work almost as well if we just ignore the call... So instead to forward the error to the application, why should we not put a nice ERR message on the console and just ignore the gamma change and return OK ?
Lionel
-- Lionel Ulmer - http://www.bbrox.org/
Sure, we could do that if gamma is truly not supported. I wrote an SDL test app compiled for both Win32 and Linux. I ran it on both my linux box, native and wine, and on my windows 2k3 box where I compiled it. Gamma was not supported on my windows box, but was supported in X on my linux box. I suppose a game should not take the failed call to SetGammaRamp as a complete failure. I suppose always returning DD_OK + a warning when gamma changes don't work would be nice too, because this could be problematic even on Windows but doesn't have to be on Wine.
participants (7)
-
Alexandre Julliard -
Chris Morgan -
Jesse Allen -
Lionel Ulmer -
Molle Bestefich -
Stefan Dösinger -
Tom Spear