On 9 September 2014 10:43, Dave Airlie <airlied@xxxxxxxxx> wrote: > 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. The only caveat we came up with is due to page_flip requiring indices we can't probably move things around as much as I'd like, I'm not sure if we have same problems further up! Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
