PATCH: video mode changes

[Alex Pasadyn]

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