role of crtcs in modesetting interfaces and possible abstraction away from userspace

[Dave Airlie]

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.