Wine, fullscreen applications, and RandR 1.2

[Henri Verbeet]

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".)

>> 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.

>> 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.

> 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.