[Bug 34348] Wine xrandr12 failure

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=34348

--- Comment #35 from Sebastian Lackner <sebastian at fds-team.de> ---
(In reply to Aaron Plattner from comment #34)
> Just in case it's gotten lost over the years, I wanted to reiterate that the
> correct fix for this is for Wine to use RandR 1.2's transforms to achieve
> the scaling it wants rather than hoping the monitor has the timings it
> expects, or relying on RandR 1.1's implicit scaling.

Wine supports RandR 1.2 of course, but can't use it in some cases. The main
reason why some people are still forced to use RandR 1.0 is:

--- snip ---
    /* Recent (304.64, possibly earlier) versions of the nvidia driver only
     * report a DFP's native mode through RandR 1.2 / 1.3. Standard DMT modes
     * are only listed through RandR 1.0 / 1.1. This is completely useless,
     * but NVIDIA considers this a feature, so it's unlikely to change. The
     * best we can do is to fall back to RandR 1.0 and encourage users to
     * consider more cooperative driver vendors when we detect such a
     * configuration. */
    if (only_one_resolution && XQueryExtension( gdi_display, "NV-CONTROL", &i,
&j, &ret ))
    {
        ERR_(winediag)("Broken NVIDIA RandR detected, falling back to RandR
1.0. "
                       "Please consider using the Nouveau driver instead.\n");
--- snip ---
( see
http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winex11.drv/xrandr.c#l479
)

Based on your email address I assume you know the reason why NVIDIA decided to
implement it that way. Do you have any better idea how to solve it, without
falling back to RandR 1.0? The wined3d developers might know better, but I
would guess that some Windows applications are not really happy when they have
only one resolution to choose from ...

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.