Hi,
I have some comments on this patch :
if (devmode->dmFields & DM_BITSPERPEL){if (devmode->dmBitsPerPel != GetSystemMetrics(SM_WINE_BPP))continue;}
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)
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.
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).
So I would say that if no VidMode is present or if the User driver function does not exist in the driver, the old 'stub' API should remain as it is.
Lionel
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
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?
Well, we should (and I have a patch to this effect sitting in my tree for a long time now). But the best would be, of course, to support both 24/24 and 24/32 properly.
But for that I need a 24/24 system to test on :-)
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?
Well, I was just saying this as you told that you needed to export this function and so I tried to propose a solution. I do not have a strong opinion on this anyway :-)
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.
Well, it's just that if I want to play in 640x480 with my standard 800x600 desktop I could change the resolution in HalfLife for example without having to change the Wine config :-)
But I agree that it's not that big a problem.
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.
Yeah, this could be possible.
Anyway, there is not only Desktop mode but people which either do not have XVidMode or who have it disabled... Should they always play HalfLife or games using their desktop size or will they be allowed to change the resolution ?
For exemple, I will always disable XVidMode in my config (I hate automatic switch as when I want really to play, I start a second X server at the right size :-) ). But I sill would like to be able to change the size of the games I want to debug.
My fear with that is that an app could think the change happened and behave badly!
Well, this is what Wine did for 10 years now and nobody ever complained :-)
Lionel Ulmer wrote:
Anyway, there is not only Desktop mode but people which either do not have XVidMode or who have it disabled... Should they always play HalfLife or games using their desktop size or will they be allowed to change the resolution ?
For exemple, I will always disable XVidMode in my config (I hate automatic switch as when I want really to play, I start a second X server at the right size :-) ). But I sill would like to be able to change the size of the games I want to debug.
Heh, well, in my testing, I saw two different kinds of apps. Some look at the results (like Warcraft) and resize to fit the window, while others (like Half-Life) ignore it and just draw whatever size you say. So, for the first kind, you would have to specify a different desktop size, but the others behave just like they always did.
My main concern would be if anything actually stopped working, but I did not find any of those...
Alex
-
Alex Pasadyn -
Lionel Ulmer