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!
I'm experiencing the same issue with modesetting+nouveau, so Intel is innocent (for once ;) )
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.
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.
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?
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!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.