Summary: | RandR unable to set Screen Size when using Intel+nouveau | ||
---|---|---|---|
Product: | xorg | Reporter: | main.haarp |
Component: | Driver/nouveau | Assignee: | Nouveau Project <nouveau> |
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
Severity: | normal | ||
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
main.haarp
2018-09-13 11:03:55 UTC
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.