I am assigning that bug to nouveau DDX, although I really won't be surprised if that is xserver or even kernel driver bug. I have two CRTCs (CRTC0 and CRTC1) (most modern cards have such number) I would like to assign CRTC1 to laptop screen, so I do this: xrandr --output LVDS-1 --auto --crtc 1 Screen does blink however doing 'xrandr --verbose' still tells me that LVDS-1 uses CRTC0. I can repeat that command again and again. If I enable kernel modesetting debug, I notice that LVDS-1 is connected once to CRTC0 and once to CRTC1 (on each invocation of 'xrandr' they change places), and it does succedd, leading me to beliving that on kernel level everything is fine. However on higher level something is really broken, as xrand insists that LVDS-1 connected to CRTC0, not to mention that such toggle of CRTCs shouln't take place as I told explicitly I want to use crtc1. This is preparation of hunt for bug that causes external connected monitor to go dark after suspend and resume cycle sometimes, then if I disconnect it, even nastier problem happends, the notebook screen goes dark as well, a thing that makes me suspect that one of CRTCs goes tits up. So I need a ability to control which CRTC is used. I am using very recent versions (from git actually) of everything related to GFX stack, although not everything is up to date, like for example xrand library. I think I will be able to handle that bug on my own, although if you have seen anything related, or maybe even fact that this is known, please tell me.
So, I understand now what is going on. Its actually a feature, very unusual and strange one. When I execute: 'xrandr --output LVDS-1 --auto --crtc 1' System does switch LVDS to CRTC1, however, xrandr also marks said CRTC as primary, which brings it to first position of crtc list in XRRGetScreenResources. and therefore on next invocation xrandr insists that output is once again connected to CRTC 0, which is technicaly true, but its different '0'. Also except reporting actual atom values, there is no way for xrandr to undo this feature which granted is to support backward compatability with older (and current?) desktops. Yet, at least xrandr could sort the crtc list and assuming that atom values for each crtc don't change (and they seem not) it'll fix this problem.
This is really strange 'feature', but still not a bug
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.