Wine, fullscreen applications, and RandR 1.2

[Andy Ritger]

On Thu, Sep 06, 2012 at 01:05:42AM -0700, Henri Verbeet wrote:
> On 5 September 2012 22:45, Andy Ritger <aritger at nvidia.com> wrote:
> > On Wed, Sep 05, 2012 at 11:26:23AM -0700, Henri Verbeet wrote:
> >> From Wine's point of view, we'd just get a bunch of extra code to maintain
> >> because nvidia does things differently from everyone else.
> >
> > Eventually, I hope NVIDIA isn't unique about this approach to viewport
> > configuration.  The drawbacks aren't NVIDIA-specific.
> >
> > The concern about added code maintenance to Wine is fair; is that concern
> > lessened if the details of viewport configuration are abstracted by a new
> > standard library?
> >
> A little, but adding extra dependencies isn't without its costs
> either. You'd also have to wait a fair bit before it ends up in common
> distributions. (And that means things like "Debian stable" or "RHEL",
> not "Ubuntu & Fedora".)

Yes; understood.

> >> Perhaps there's a use case for a "big screen" setup, but that too is
> >> something that's probably best handled on the RandR / X server level
> >> instead of Wine.
> >
> > I don't think we can have it both ways:
> >
> > * RandR 1.1 gives you one "big screen" per X screen; the user can
> >   configure what is within that big screen via NVIDIA's MetaModes.
> >
> > * RandR 1.2 gives applications control of each individual CRTC/output.
> >
> > Are you suggesting we go back to something more like RandR 1.1?
> >
> I imagine you could configure things in e.g. xorg.conf so that the
> displays show up as a single CRTC / output instead of individual
> CRTCs, perhaps depending on how the MetaModes are setup. Or perhaps
> there's some way to make this fit it with some of the new
> functionality in RandR 1.5. The main point though is that there's no
> reasonable way for Wine to decide to do one or the other
> automatically. We could of course add a configuration option for that,
> but at that point it makes more sense to do it globally for all
> applications in RandR or the X server.

RandR 1.2+ intentionally gives control of the individual CRTCs/outputs
to client applications, with the goal of moving display configuration
policy out of the X server.  But I agree it is a burden for every
fullscreen application to have to decide for itself how to configure
the available CRTCs/outputs.

Here again maybe some helper library can help bridge the gap.

> >> I don't think you can actually do "immersive gaming"
> >> properly without support from the application though, you'll get
> >> fairly significant distortion at the edges if you just render to such
> >> a setup as if it was a single very wide display.
> >
> > I'm sorry; I don't understand the distortion concern.  Are you referring
> > to the bezel of the monitor occupying physical space, but not pixel space
> > in the X screen?  I believe people often address that by configuring
> > "dead space" in the X screen between their monitors.
> >
> No, I mean the distortion caused by perspective projection, because
> you're essentially projecting a spherical "world" onto a flat screen.
> An application that is aware of this could e.g. use a separate camera
> for each display to mitigate this, or perhaps adjust the projection
> matrix.

Maybe there is a distortion concern in theory (though it may depend on
whether the monitors are all in the same plane or tilted to "wrap around"
the user), but in practice it seems to normally work out well enough.
I suppose maybe users use side displays for peripheral vision, and then
move their viewport such that the content they care about is in the
center display.

In any case, there is an enthusiast community around immersive gaming; e.g.,

    http://www.nvidia.com/object/3d-vision-surround-technology.html

In those cases, the content across the monitors is rendered as one
big screen, rather than rendered separately per display with different
view frustums.

With RandR 1.1 + NVIDIA MetaModes, users could achieve that sort of
configuration with Wine.  They can't really do that now with Wine and
RandR 1.2.

> > Since we have some differing viewpoints that won't be quickly resolved,
> > how about as a compromise we add a way for users to force Wine from
> > RandR 1.2 back to RandR 1.1?  That would at least let users achieve
> > some of the configurations they cannot configure with top of tree.
> > If that seems fair, what is the preferred configuration mechanism to
> > do that?  Just a simple environment variable?
> >
> You could perhaps extend the existing "UseXRandR" registry setting
> (see dlls/winex11.drv/x11drv_main.c) to take a version number. It's
> not something we've heard a lot of users about though.

Sounds good; I'll look into that.

Thanks,
- Andy