Nouveau - Sep 2018 - [Bug 107919] New: RandR unable to set Screen Size when using Intel+nouveau

https://bugs.freedesktop.org/show_bug.cgi?id=107919

            Bug ID: 107919
           Summary: RandR unable to set Screen Size when using
                    Intel+nouveau
           Product: xorg
           Version: unspecified
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Driver/nouveau
          Assignee: nouveau at lists.freedesktop.org
          Reporter: main.haarp at gmail.com
        QA Contact: xorg-team at lists.x.org

I am using a Thinkpad W530 which features an Intel GPU (Ivy Bridge) hooked up
to the internal LCD and an Nvidia K2000M (NVE7/GK107) hooked up to the
DisplayPorts.

Gentoo Linux
Kernel: 4.14.65
xorg-server-1.19.5
xf86-video-intel-2.99.917_p20180214
xf86-video-nouveau-1.0.15


Both GPUs drive outputs via "xrandr --setprovideroutputsource nouveau
Intel".
Under these conditions, changing monitor layouts works once. Then, when the
laptop is suspended and brought to a different workplace with a different
monitor layout, most subsequent xrandr calls fail. RRSetScreenSize refuses to
work. Example:

    xrandr --output LVDS1 --mode 1920x1080 --pos 0x0 --rotate normal
    xrandr --output DP-1-2 --primary --mode 2560x1440 --pos 1920x0 --rotate
normal
    xrandr --output DP-1-3 --mode 2560x1440 --pos 4480x0 --rotate normal

Result:

X Error of failed request:  BadValue (integer parameter out of range for
operation)
  Major opcode of failed request:  139 (RANDR)
  Minor opcode of failed request:  7 (RRSetScreenSize)
  Value in failed request:  0x0
  Serial number of failed request:  57
  Current serial number in output stream:  58


Once this bug appears, xrandr behaves pretty strangely and "randomly"
as far as
requested changes go:

- xrandr refuses to set some modes/positions/rotations
- This can be partially mitigated by toggling outputs off entirely and on
again. xrandr will still complain, but do as told
- Trying many different modes/positions/rotations and off/on cycles may
eventually yield the desired layout
- Attempts to change the screen size directly with e.g. "xrandr --db
9999x9999"
fails with the same error
- Something simple like making an active output primary, e.g. "xrandr
--output
DP-1-2 --primary" fails with the same error
- Setting the same layout that is currently active is also complained about
- xrandr calls that previously failed may suddenly work after waiting a few
hours

Neither the kernel nor X show any relevant logs. I will check other debug
levels as instructed.

If you would like me to test anything or need more information, please let me
know.
Thanks!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20180913/f1538133/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=107919

--- Comment #1 from main.haarp at gmail.com ---
I'm experiencing the same issue with modesetting+nouveau, so Intel is
innocent
(for once ;) )

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20181003/cc7b7a3e/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=107919

--- Comment #2 from main.haarp at gmail.com ---
Kernel 4.18.16
xorg-server-1.20.3
xf86-video-nouveau-1.0.15

Using modesetting driver for the Intel chip.

This bug still remains. It makes using this kind of laptop on different
workplaces a disaster. Switching monitor layouts is painful to impossible. Even
simple things such as setting an output as primary fail, which turns most
desktop environments into a nightmare.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20190121/7dfd7b59/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=107919

--- Comment #3 from Ilia Mirkin <imirkin at alum.mit.edu> ---
The way RandR works is that it will create one giant FB for all your monitors,
and then tell each crtc to scan out a portion of it. The intel max on IVB is
most likely 8k, but having trouble confirming it. This can come into play when
you're turning things on and off, and they're placed "far
out", even if the
desired configuration does fit well.

There's no real benefit to using nouveau ddx for the secondary screens, so
you
should also experiment with using modesetting for those.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20190121/e51c7241/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=107919

--- Comment #4 from main.haarp at gmail.com ---
Thanks for your reply, Ilia.

(In reply to Ilia Mirkin from comment #3)
> The intel max
> on IVB is most likely 8k, but having trouble confirming it.
This is correct, xrandr reports a maximum of 8192x8192.

However, when not using nouveau (i.e. this bug is not triggered), I'm
getting
the error message

xrandr: screen cannot be larger than 8192x8192 (desired size 9999x9999)

While the error I'm getting when this bug is triggered is different:

X Error of failed request:  BadValue (integer parameter out of range for
operation)
  Major opcode of failed request:  139 (RANDR)
  Minor opcode of failed request:  7 (RRSetScreenSize)
  Value in failed request:  0x0
  Serial number of failed request:  57
  Current serial number in output stream:  58

It's also weird that something that shouldn't touch the FB, such as
setting a
primary output, also fails with this.


Another note: Before Nouveau, I ran the Nvidia card with the propietary driver
on a separate X server together with intel-virtual-output. i-v-o provides
virtual outputs on the Intel side and proxies them to the second X server.

While the performance was terrible (which is why I switched to
nouveau+provideroutputsource, thanks so much for creating Nouveau!), there were
no problems setting screen sizes. But maybe i-v-o also used some sort of magic.

> There's no real benefit to using nouveau ddx for the secondary screens,
so
> you should also experiment with using modesetting for those.
Ah, I didn't know this was possible. I will of course lose the last remnants
of
rendering performance from the Nvidia, but if it allows monitors to work well,
that's worth it. I will try that once I have the time. I assume this will
not
help with IVB's small FB, correct?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20190205/7add46bd/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=107919

main.haarp at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #5 from main.haarp at gmail.com ---
I have not encountered this bug recently. This is either due to a kernel
upgrade (using 4.19 now) or some package having received an upgrade. I suspect
the kernel.

I'm closing this. Thank you, nouveau developers!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20190225/d896025f/attachment.html>