Re: Wine, fullscreen applications, and RandR 1.2

[Andy Ritger]

On Sat, Sep 08, 2012 at 12:08:06AM -0700, Henri Verbeet wrote:
> On 8 September 2012 01:22, Andy Ritger  wrote:
> > 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.
>
> How does that work in Windows? In a typical D3D9 application you would
> normally end up with one adapter per display. Unless the application
> is multihead aware, switching to fullscreen mode would just make the
> application fullscreen on the primary display. Does the display driver
> change how the displays are presented to the application?

Yes.  As I understand it: the NVIDIA Windows driver, to support those
sorts of immersive gaming configurations, presents one adapter to the
Windows OS, which in turn presents that one adapter to the application
(e.g., one 7680x1600 adapter, rather than 3 2560x1600 adapters).
This is conceptually similar to NVIDIA Linux driver's MetaMode + RandR
1.1 (or XF86VidMode).

There are definitely cases where you would want the application to
be multihead aware so that they can make more intelligent use of each
monitor.  But in the case of monitors with similar geometry, abstracting
the complexity of multiple monitors away from the application has had
some success.

Somewhat timely, a related article was just posted on phoronix:

http://www.phoronix.com/scan.php?page=news_item&px=MTE3OTQ

That article suggests that there should be some coordination between
fullscreen applications and window managers.  Since that would also
introduce complexity, and would be needed across multiple applications
(and multiple window managers), a suspect one or more helper libraries
to centralize and abstract the complexity might be a good approach.

Thanks for the feedback in this thread.  I'll give some thought to what
these sorts of helper libraries might look like.

Thanks,
- Andy