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