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

[Rob Clark]

On Wed, Sep 10, 2014 at 4:20 AM, Ville Syrjälä
<ville.syrjala at linux.intel.com> wrote:
> On Tue, Sep 09, 2014 at 07:22:49PM -0400, Rob Clark wrote:
>> 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.
>
> I disagree. User space can be in a much better position to pick the
> crtc, especially in more product oriented scenarios. Eg. a tablet/phone
> where user space knows that it should use the more capable crtc for the
> internal display and less capable one for the external display. The
> reason for this could be that it will be presenting video in a window
> on the internal display and fullscreen on the external display.

Sure, but this is a pretty special case from an upstream perspective.
But giving userspace the choice of picking explicitly or letting
kernel pick, I think we can accommodate both the weird special cases,
as well as the common case.

Not quite sure how it would work from atomic ioctl standpoint, where
userspace needs to set (potentially) multiple properties on several
unchosen crtc's, but I think we could have userspace pick virtual crtc
id's, ie.

  #define VIRT_CRTC 0x40000000

then user uses (VIRT_CRTC | 1), (VIRT_CRTC | 2), and so on.. then
kernel somehow resolves those into actual crtc id's..

>>
>> 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.
>
> Then you get to figure out how to deal with all/some of the properties
> effectively changing values when the crtc changes. I guess you could
> just specifiy that this will happen and it's up to userspace to provide
> the full state if it wants to avoid unexpected property values.

Well, we still need to define what the semantics are for unspecified
property values, esp. if different ctrc's had different properties.  I
think "preserve" for pageflip and "reset to default" for modeset would
be the sane choice, although it is a bit awkward with both crammed
into the same ioctl.  Probably we end up adding a flag to control the
behaviour.

But yeah, playing switch-a-roo under the hood, we have to sort out
those details.  But at least it would happen only at modeset where
userspace probably wants to use the hypothetical
RESET_UNSPECIFIED_TO_DEFAULT flag..

BR,
-R


> --
> Ville Syrjälä
> Intel OTC