On 5 September 2012 22:45, Andy Ritger aritger@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.