Thanks, Henri.
On Wed, Sep 05, 2012 at 01:34:47AM -0700, Henri Verbeet wrote:
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.
Thanks for clarifying.
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 480It'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.
At first glance, I agree that would be easier for applications, but that approach has some drawbacks:
* lies to the user/application about what timings are actually being driven to the monitor * the above bullet causes confusion: the timings reported in the monitor's on screen display don't match what is reported by the X server * user/application doesn't get complete control over what actual timings are being sent to the monitor * does not provide the full flexibility of the hardware to configure, e.g., arbitrary position of the ViewPortOut within the active raster
I imagine counter arguments include:
* we already have the "scaling mode" output property in most drivers; that is good enough * Transformation matrix and Border are too low level for most applications
For the first counter argument: I'm trying to make the case that providing the full flexibility, and being truthful about modetimings to users/applications, is valuable enough to merit a change (hopefully even in the drivers that currently expose a "scaling mode" output property).
For the second counter argument: maybe the viewport configuration belongs in a library rather than directly in applications like Wine. In that case, I'd like to build a better understanding of Wine's needs so that I could properly design the API to such a library.
- 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.
That is true most of the time, but I don't believe it is strictly mandated by the RandR specification:
http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt
When the RandR primary output (as queried/set by RR[SG]etOutputPrimary) is non-None, then its CRTC will be sorted to the front of the CRTCs list reported by RRGetScreenResources{,Current}. However, None is a valid value for the primary output, in which case all bets are off wrt CRTC/output sorting order in the RRGetScreenResources{,Current} reply.
Further, while RandR primary output seems like a reasonable default, the spec spells out a focus on window manager (e.g., "primary" is where the menu bar should be placed). It seems like a valid use case would be for the user to have his window manager primary output on one monitor, but run his full screen Wine application on another monitor. Given that, would it be reasonable for the user to specify the RandR output he wants Wine to use?
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.
I can definitely believe that plumbing RandR outputs to multiple objects in Win32 is not an important/compelling use case, since not many Win32 applications would do useful things with that. What seems more useful, though, is driving multiple RandR outputs and presenting that to Win32 as a single big screen. E.g., "immersive gaming" where your Wine application spans two, three, or more RandR outputs (NVIDIA Kepler GPUs can have up to four heads).
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.
There were plenty of deficiencies in RandR 1.1 and NVIDIA's implementation of it, but with MetaModes the user could configure whatever combinations of displays he wanted. You are right, though, that any displays not in the MetaMode would get turned off when RandR 1.1 switches to it.
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.
I agree that displays not used by Wine should be left alone, not turned off.
But you said above that most Win32 applications don't natively take advantage of multiple displays themselves. I expect some users are interested in having their Wine application fullscreen across multiple displays. Does that seem reasonable?
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.
Yes, the fake refresh rate reporting in DynamicTwinView was unfortunate, but was necessary in RandR to distinguish between MetaModes of the same size. Now that we have RandR 1.2, hopefully we can move past that.
Thanks, - Andy