On 5 September 2012 08:07, Andy Ritger aritger@nvidia.com wrote:
Questions:
- Looking at dlls/winex11.drv/xrandr.c, the first RandR CRTC/output's modelist is used to populate Wine's list of available modes. Is the data flow between Wine and Windows applications always such that you need to advertise a list of (width, height, refreshRate)s? Or would an application ever tell Wine what resolution it wants?
Windows applications use EnumDisplaySettingsEx() to query supported modes, and ChangeDisplaySettingsEx() to set one. Applications can't make up modes on their own.
Would you be open to patches to make dlls/winex11.drv/xrandr.c generate a larger set of (width, height, refreshRate)s, and then have xrandr12_set_current_mode() use RandR transformation matrix and Border property to satisfy those? I was envisioning something where we take the "preferred" mode for the RandR output, and create all of the following resolutions using ViewPort{In,Out}:
1920 x 1200 1920 x 1080 1600 x 1200 1280 x 1024 1280 x 720 1024 x 768 800 x 600 640 x 480
It's ultimately not up to me whether such a patch would be accepted, but it's not something I would be particularly happy about. I think the preferred way to handle this would be to generate the standard DMT etc. modes in the kernel, and use the "scaling mode" output property to control the scaling mode, pretty much like all the other drivers.
- The current xrandr.c code picks the first CRTC/output, which may not be currently active. At the least, it should scan for an active CRTC+output. I imagine it would be even better if the user could configure which RandR output they want. Would that be reasonable? What mechanisms are available in Wine for users to provide runtime configuration?
The RandR primary display should be CRTC 0, output 0. Users can typically change this through xrandr or xorg.conf. Unfortunately not all drivers do something reasonable by default here, so we'll probably add code to pick the first connected display as Win32 primary instead if no primary is defined through RandR. For the moment we end up falling back to the older RandR version though, so at least the behaviour isn't any worse than before.
- From the current code, it does not look like Wine's RandR support tries to do anything with multiple simultaneous RandR outputs.
Yes, proper multihead support is something we still need to implement. There aren't a lot of Win32 applications that do something useful with multiple displays though, so it's not something that has a very high priority at the moment.
Ironically: this actually works better with RandR 1.1 + NVIDIA: users can configure their MetaModes to describe what mode (plus viewport configuration) they want on each monitor, and then RandR 1.1 chooses the MetaMode.
No. With RandR 1.1 you get one big screen, and you can choose between getting fullscreen applications stretched across all your displays, or turning off all displays except one. What you actually want is for the application to be fullscreen on a specific display, or multiple displays if the application supports that, and leave everything else alone.
As an aside, the fake refresh rates generated by "DynamicTwinView" aren't very helpful either. Some Win32 applications expect modes like 800x600@60Hz or 1024x768@60Hz to always exist, and just die if they don't.