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

[Rob Clark]

On Tue, Sep 9, 2014 at 4:16 AM, Ville Syrjälä
<ville.syrjala at linux.intel.com> wrote:
> 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.

first off, I tend to think with the trend towards various different
wayland compositors doing kms directly, making it easier for userspace
sounds pretty attractive.  Ie. would you rather fix a bug w/ picking
the right crtc for the job in N compositors, or 1 kernel driver?

But that said, it seems like the real problem w/ kernel picking the
right crtc is going to be with non-atomic modeset.  And for pre-atomic
(future legacy) xrandr, I'm not entirely sure how userspace is
supposed to do a better job at this than the kernel could.  It would
also need up front knowledge of all the modes that would be picked.
So you've just pushed non-atomic suck in the kernel to non-atomic suck
in x11.  Doesn't sound like that fixes anything.

But, I think there is maybe a way to have our cake and eat it too.. to
leave extra flexibility for highly customized/specialized userspace,
we could just allow for some PICK_ANY_CRTC_FOR_ME type value which
would let 99% of userspace push the decision to the kernel, while
still allowing for the special cases where userspace knows better.

BR,
-R

> So no, I don't think this is a good idea given real world hardware
> constraints.
>
> --
> Ville Syrjälä
> Intel OTC
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel