PATCH: video mode changes
ajp at mail.utexas.edu
Sat Apr 12 10:53:13 CDT 2003
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
>>+ 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
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!
More information about the wine-devel