Wine, fullscreen applications, and RandR 1.2

[Andy Ritger]

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