Wine, fullscreen applications, and RandR 1.2

Hello wine developers, I work on NVIDIA's Linux graphics driver team, and have a few questions about how Wine should interact with X driver mode lists. Sorry if this isn't the correct forum for these questions. Starting in release 302.xx, we finally added RandR 1.2 support to NVIDIA's X driver. At the same time, we reworked some things about how modetimings are validated and configured by the NVIDIA X driver. For the following, the important part is that we eliminated implicit flat panel scaling, and instead made it explicitly configurability through NVIDIA's MetaMode syntax and through RandR 1.2. The user-visible change is that only modes reported by a digital flat panel's EDID are in the mode list for an RandR output. A little background: modern GPUs (at least NVIDIA, and I expect other vendors) have a flexible display scaling pipeline that consists of: * A "RasterSize": this is the resolution of pixels that will be sent to the monitor; this is what people normally think of as the size of the "mode". * A "ViewPortIn": this is the resolution of pixels that the display engine will fetch from the X screen. * A "ViewPortOut": this is the region _within_ the RasterSize to which the pixels of ViewPortIn should be sent. The pixels fetched in ViewPortIn can be scaled up or down by specifying different sizes for ViewPortIn and ViewPortOut. Also, letterboxing and overscan compensation can be configured by making ViewPortOut smaller than RasterSize. For example, if your monitor accepts a mode of 1920x1200, and you want a desktop resolution of 1280x720 aspect-scaled to fill 1920x1200 (i.e., 1280x720 scaled to 1920x1080, with 60 blank scanlines above and below it in a 1920x1200 mode), then in NVIDIA MetaMode syntax you could do: "1920x1200 { ViewPortIn = 1280x720, ViewPortOut = 1920x1080+0+60 }" While the MetaMode syntax is NVIDIA-specific, the same can be configured through RandR: * The RandR transformation matrix can be used to describe the scaling between ViewPortOut and ViewPortIn. * The RandR "Border" output property can be used, when available, to describe a ViewPortOut that is smaller than the RasterSize. Note: most RandR X drivers, including NVIDIA, don't yet provide this property, though I'm in the process of adding it for NVIDIA. In practice this means that most resolutions (i.e., not just a fixed modelist), from the perspective of desktop size, are achievable with RandR. 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? * 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 * 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? * From the current code, it does not look like Wine's RandR support tries to do anything with multiple simultaneous RandR outputs. 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. Would it make sense for the user to be able to specify to Wine the RandR configuration (spanning all of the RandR outputs on the X screen)? I guess that depends on what runtime configuration mechanisms are possible. I'm curious what you guys think, before I code up any patches to propose. Thanks, - Andy Ritger