Wine, fullscreen applications, and RandR 1.2

Henri Verbeet hverbeet at
Wed Sep 5 03:34:47 CDT 2012

On 5 September 2012 08:07, Andy Ritger <aritger at> wrote:
> 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?
Windows applications use EnumDisplaySettingsEx() to query supported
modes, and ChangeDisplaySettingsEx() to set one. Applications can't
make up modes on their own.

> * 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
It's ultimately not up to me whether such a patch would be accepted,
but it's not something I would be particularly happy about. I think
the preferred way to handle this would be to generate the standard DMT
etc. modes in the kernel, and use the "scaling mode" output property
to control the scaling mode, pretty much like all the other drivers.

> * 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?
The RandR primary display should be CRTC 0, output 0. Users can
typically change this through xrandr or xorg.conf. Unfortunately not
all drivers do something reasonable by default here, so we'll probably
add code to pick the first connected display as Win32 primary instead
if no primary is defined through RandR. For the moment we end up
falling back to the older RandR version though, so at least the
behaviour isn't any worse than before.

> * From the current code, it does not look like Wine's RandR support tries
>   to do anything with multiple simultaneous RandR outputs.
Yes, proper multihead support is something we still need to implement.
There aren't a lot of Win32 applications that do something useful with
multiple displays though, so it's not something that has a very high
priority at the moment.

>   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.
No. With RandR 1.1 you get one big screen, and you can choose between
getting fullscreen applications stretched across all your displays, or
turning off all displays except one. What you actually want is for the
application to be fullscreen on a specific display, or multiple
displays if the application supports that, and leave everything else

As an aside, the fake refresh rates generated by "DynamicTwinView"
aren't very helpful either. Some Win32 applications expect modes like
800x600 at 60Hz or 1024x768 at 60Hz to always exist, and just die if they

More information about the wine-devel mailing list