Lionel Ulmer wrote:
This may cause problems... It's not per-se a problem in your patch, but from what I know Windows applications expect to have '32' on a 24/32 display and Wine stores here '24'.
So you may 'refuse' some modes that should be valid.
(again, if ever you have a graphic card still supporting 24/24 mode, please tell me so that I can torture your XFree libraries to find a valid way of checking the difference between 24/24 and 24/32)
That's a good point. I was doing all my testing in 16-bit modes. I shall try some with higher bit depths and see what happens. I was concerned about reporting a mode that is not real as the application could think it really got the bit depth it asked for and do something bad. (The old code with the hardcoded depths did this, but I would always pick the one that matched my X depth anyway whenever the app gave me a choice.) Could it just be that if the depth is 24, we should return 32?
SYSMETRICS_Set( SM_CXSCREEN, devmode->dmPelsWidth );SYSMETRICS_Set( SM_CYSCREEN, devmode->dmPelsHeight );This are actually 'User' internal functions ? In that case, why not just do the resolution change in the X11 driver and let User itself handle the sysmetric change ? I.e. call these in the 'ChangeDisplaySettingsExW' function and not in the low-level graphic driver.
I did it this way because I asked Alexandre about splitting between USER and X11DRV and he said it was best to put all the functionality in X11DRV, at least for now, in case some other driver needed a different split. I believe that some of it surely could be in USER as I think it would apply to all drivers. Does anyone else have strong opinions?
Now my most important grief : did you think about all the people who 1) use Desktop mode and 2) disable XVidMode in their config file ? For those, applications may now abort saying 'Vidmode not supported' (whereas it was working just fine before because we accepted all modes that are smaller than the actual screen size).
Actually, I did think about that a lot. The main applications I was using to test were Warcraft III, Half-Life, and the NeHe OpenGL tutorials. Warcraft seemed much happier with the behavior in this patch. If I ran it in desktop mode, the game automatically sized itself to the size of the desktop. If I wanted to change the size, I just defined the desktop to be a different size. Previously, it could either make itself too big or too small for the desktop. The others handled the lack of switching gracefully.
The applications seem to fall into two categories: those that call EnumDisplaySettings and pick one, and those that only call ChangeDisplaySettings without checking first. The first category (Warcraft) seem to do really well. The second category (Half-Life, NeHe OpenGL tutorials) would probably like some more leniency, but they behaved fine. Is there a specific application that is giving trouble with this?
The desktop or "real" size is returned as the only available mode if XVidMode is disabled. I personally think this behavior makes sense. If I want the app to be a different size, I give it a custom desktop setting in the config file. The other option that seemed interesting would be to consider allowing changing of the size of the desktop window.
Perhaps a compromise would be to just return success if the requested mode is smaller than the allowed ones (or the desktop of XVidMode is disabled)? My fear with that is that an app could think the change happened and behave badly!
Alex Pasadyn