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

[David Herrmann]

Hi

On Tue, Sep 9, 2014 at 10: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:
>> 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.

I agree with Ville here. For generic DRM usage, it's irrelevant which
CRTC is used, but for special use-cases you want more capable CRTCs
for the display you use for compositing. Sure, this might be solved
with simple "hints" you pass to the kernel, but those hints pretty
soon become what we now have as CRTCs. And re-configuration requires
expensive deep modesets so cannot be done on-the-fly by the kernel
once user-space allocates resources for a given output.

However, the way we pick CRTCs and encoders today is already
problematic. If you write gpu-specific drivers, you know the hardware
perfectly, but generic drivers already need to do trial-and-error.
Especially, if you want "clone" mode, you have no control which
encoder is picked by the kernel, so you don't know which one is left
after the first mode-set, so you cannot know which CRTCs are available
for the other connectors.
No driver exposed such restricted and backwards interfaces so far, and
the CRTC->encoder->connector graph is almost always a tree. But you
can't be sure, if you write generic drivers.. so for all stuff I did
so far, I already use "connectors" as primary objects and re-evaluate
after each single modeset. So it wouldn't change much if CRTCs aren't
exposed at all.

I also agree with Keith: Somewhere in the stack, there has to be a
layer that adds "screens", which are possibly composed of multiple
connectors. If we do this in user-space (like we all do so far), we
can support setups where multiple real displays are composed into a
single large screen *AND* setups, where one display is internally
represented by multiple displays. If we do it in the kernel, we might
possible require a second such layer in user-space..

Long story short: I'm totally fine with exposing split hardware as
multiple connectors..

Thanks
David