crtc ganging in KMS, "large" displays, etc

[Daniel Vetter]

On Mon, Mar 31, 2014 at 02:04:00PM -0400, Rob Clark wrote:
> I thought I'd kick off a thread to better discuss how to deal with
> "large" displays which need multiple crtcs/planes merged to deal
> without output larger than a certain width.
> 
> What I have in mind basically amounts to driver-custom-properties and
> shouldn't really need much/anything in the way of drm core or helper
> support[1].  There may of course be some room to make helpers/core
> more aware of crtc ganging if it turns out to be something that many
> drivers are doing in the same way.  But to start with my bigger
> concern is getting the userspace interface right.
> 
> This is semi-related to a thread started earlier by Aaron Plattner on
> xorg-devel:
> 
> http://lists.freedesktop.org/archives/xorg-devel/2014-January/039984.html
> 
> As I see it, there are really two different scenarios:
> 
> 1) single encoder/connector:  double up on planes (pipes) and crtcs
> (mixers), but still a single connector.
> 
> 2) double up entire pipe.. this scenario is more like what Aaron
> mentioned.  This could mean using multiple DVI or HDMI connectors, or
> multiple DSI channels.  In the DSI case, I'm not entirely sure yet the
> implications for a dsi panel driver, but I think it needs to be a bit
> aware.

I think this here is (mostly) a userspace problem of figuring out how the
different outputs are laid out in reality. Only difference is that the hw
might (not sure how far those standars really are) provide some definit
hints. So imo not a kernel problem really.

> -------------------
> 
> For the first scenario, the approach I am leaning towards is a
> 'SLAVE_CRTC'[2] property on the crtc.  The idea being that userspace
> could pick an otherwise unused CRTC, and assign it as a slave in order
> to enable higher resolutions.  The primary crtc could use the slave's
> mixer and primary plane.  The existing encoder->possible_crtcs would
> be used by userspace to figure out which crtc(s) it could pick to use
> as a slave.
> 
> The property approach seems like it should fit in nicely with the
> plans for atomic.  The driver can decide whether a given mode is
> possible during the atomic 'test' step based on the proposed
> SLAVE_CRTC value.  We do possibly get funny edge cases where a CRTC
> isn't yet available but will be after next vblank, but this is
> basically the same scenario with have already with moving planes
> between crtcs (and where an EBUSY or similar return value from atomic
> would make sense).
> 
> For non-primary planes, it may be sufficient to expose max
> width/height dimensions and let userspace figure out when it needs to
> use multiple planes for a single layer.

I second the idea of exposing plane limits. I've cc'ed a thread on
dri-devel where Damien&I discussed this a bit. We probably need a pile of
per plane/per pixel format properties like max/min size, stride and a
pile of flags for special cases.

For the crtc ganging I wonder whether we even should expose this. For
generic userspace it's just yet another random hardware restriction. E.g.
in i915 we don't expose the various (and constantly changing between
platforms) restrictions on plls. All we do is tell userspace that it
didn't work out.

Imo the point of atomic modesets with the test mode is that we can expose
this information at least indirectly to userspace. But trying to come up
with some explicit scheme for every insane corner case is imo pointless -
generic userspace won't ever bothering with them, and if you need special
code you might as well bake in the assumptions in userspace. Kinda like
current userspace has baked-in assumptions about how a fb backing storage
object should look like.

So overall I think we need to have the following pieces:
- Plane limits so that fbcon and userspace which can't do tiling can
  restrict itself appropriately.
- When userspace asks for a big mode which needs ganging of some stuff the
  kernel driver handles all the resource allocation. If your hw allows it
  it's obviously best if you can freely reassign resources between crtcs,
  otherwise it'll be really hard for userspace to get anything done
  without atomic modesets.
- Generic userspace slices&dices the logical framebuffer into tiles which
  fit into the planes.

Or do I miss something big here?

> For the second scenario, I am less sure.  We could of course also have
> some sort of 'SLAVE_CONNECTOR' property (since encoders themselves
> don't currently have/need properties).  But this probably depends on
> the outcome of the xorg/xrandr userspace discussion.
> 
> Anyways, I'd of course be interested to hear from others who will have
> to tackle the same problem in their own drivers, whether the
> 'SLAVE_CRTC' approach works for them or not, etc.  It looks like the
> first scenario is something I'll get to deal with pretty soon now (ie.
> approximately as soon as I buy myself a 4k DP monitor ;-))

Like I've said I think the 2nd scenario isn't a kernel issue (maybe we
need to expose layout information through read-only properties if it's not
available in a standard way). For the first scenario I still have the
impression that I'm missing something.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch