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

[Ville Syrjälä]

On Tue, Sep 09, 2014 at 10:43:35AM +1000, Dave Airlie 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.

Not all CRTCs are created equal so the user probably wants know what
features to expect from a particular CRTC. Now, often that may have
something to do with the planes, but there are other hardware features
that we want to expose as CRTC properties. If we make all CRTCs appear
uniform to userspace the user may not know beforehand that certain
features can only be used on a subset of CRTCs. Also if the driver
would initially pick the wrong CRTC, and later the user would enable
one of those special features, we'd have to do a full modeset to switch
hardware CRTCs which would mean a nasty screen blink for the user.

So no, I don't think this is a good idea given real world hardware
constraints.

-- 
Ville Syrjälä
Intel OTC