On January 30, 2004 09:00 am, RemiAssailly@aol.com wrote:
I don't understand you ! Without that it does not work. With that, it works and graphic working is faster.
Maybe so, but it looks obviously incorrect. Not everything that seems to fix problems is a real fix. You maybe hiding a bigger issue. The fix as you sent it can't be right, but you maybe on to something. Someone knowledgable in the area should express a more informed opinion.
Dimitrie O. Paun wrote:
On January 30, 2004 09:00 am, RemiAssailly@aol.com wrote:
I don't understand you ! Without that it does not work. With that, it works and graphic working is faster.
Maybe so, but it looks obviously incorrect. Not everything that seems to fix problems is a real fix. You maybe hiding a bigger issue. The fix as you sent it can't be right, but you maybe on to something. Someone knowledgable in the area should express a more informed opinion.
Here's the deal. ChangeDisplaySettings used to always return success, even though it actually did nothing. When I added support for resolution changing using XRandR, one of the changes was to actually fail if the requested mode did not exist.
If XRandR or XVidMode is used, the requested mode must really exist, or you will get an error. In desktop mode, there is a hardcoded list of allowable modes that covers all the commonly used ones.
The original post about this issue included an error message that included the string (NoRes) in it, which meant that XRandR, XVidMode, and desktop mode were all disabled.
While I think the correct fix is for the user to enable desktop mode or real resolution changing, there is a different hack that can be used without causing crashes.
Simply go into X11DRV_ChangeDisplaySettingsExW and replace both instances of DISP_CHANGE_BADMODE with DISP_CHANGE_SUCCESSFUL.
Alex
On January 30, 2004 01:17 pm, Alex Pasadyn wrote:
While I think the correct fix is for the user to enable desktop mode or real resolution changing, there is a different hack that can be used without causing crashes.
OK, I must admit I don't remember the thread, but why the crashes if the res change was not successful? I don't really see the need for the hack that you propose. Why do we need to lie that we changed the resolution, when we didn't? Whould that potentially result in other problems?
Dimitrie O. Paun wrote:
OK, I must admit I don't remember the thread, but why the crashes if the res change was not successful? I don't really see the need for the hack that you propose. Why do we need to lie that we changed the resolution, when we didn't? Whould that potentially result in other problems?
I don't really think it's needed either. The "problem" is that it used to always just return success, and some users are accustomed to that behavior. Basically, the game would then make for instance a 640x480 unmanaged window in the top left corner of the screen. To not get the error now, the user needs to edit the config file to either enable resolution switching (their X server must support it, too) or switch that app to desktop mode (ChangeDisplaySettings will resize Wine desktops too). The default config file has resolution changing enabled, but if the X server does not support it, the user would need to specify desktop mode themselves.
With all those options disabled, the behavior we have is the same as you get on Windows if you try to change to a mode that the graphics adapter cannot do. In my testing, I found that many of the games don't even look at that return code, but the ones that do will complain and refuse to run if they can't change the resolution to what they want.
I guess it's possible that there exists an app that breaks in desktop mode, and someone with an X server that cannot change resolutions wants to run it, but if that's the case I would like to hear about it and fix its problem with desktop mode. The original post was about StarCraft, which runs fine for me both in desktop mode and if I let it change the resolution.
Alex
-
Alex Pasadyn -
Dimitrie O. Paun