Hi, So I've been attempting to hide the 30" Dell MST monitors in the kernel, and ran into a number of problems, but the major one is how to steal a crtc and get away with it. The standard scenario I have is CRTC 0: eDP monitor connected hotplug 30" monitor, userspace decides to configure things as CRTC 1: DP-4 - 30" monitor CRTC 2: eDP-1 But since we lack atomic it does this in two steps, so when I get the first modeset to set the 30" monitor up I go and use CRTC-2 as the secondary crtc, as CRTC-0 is in use still, then I have to fail the second modeset, and things end up with me crying. So this led me to wonder why we expose CRTCs at all, and KMS does it because randr did it, but I've no idea why randr did it (Keith??). >From my POV I don't think the modesetting interface needs to take crtcs, just connectors and modes, so I'm wondering going forward for atomic should we even accept crtcs in the interface, just a list of rectangles, connectors per rectangle, etc. Now I'm at the point of trying to work out if I can make DP MST monitors a possibility before we get atomic, Myself and Ben discussed this here and he suggested we should make the userspace crtc ids pretty much meaningless and not have them tied to actual hw crtcs, so we can reroute things underneath userspace without changing it. Any input is welcome! Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
