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

[Dave Airlie]

On 9 September 2014 10:43, Dave Airlie <airlied at gmail.com> 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.