On Fri, 17 Jan 2020 10:51:45 -0600
Matt Hoosier <matt.hoosier@gmail.com> wrote:

> Hi all,
> 
> I'm confronting a situation where the hardware with which I work is capable
> of driving connectors at 4K or 8K, but doing so requires bonding the
> scanning of multiple planes together.
> 
> The scenario is that you'd have a big primary framebuffer whose size is too
> large for an individual hardware scanning pipeline on the display
> controller to traverse within its maximum allowed clock rate.
> 
> The hardware supplier's approach is to assign multiple planes, which in the
> KMS driver map to hardware scanning pipelines, to each be responsible for
> scanning a smaller section of the framebuffer. The planes are all assigned
> to the same CRTC, and in concert with each other they cover the whole area
> of the framebuffer and CRTC.
> 
> This sounds a little bit wild to me. I hadn't been aware it's even legal to
> have more than one plane treated a the source of scanout for a single
> framebuffer. Maybe that distinction isn't really relevant nowadays with
> universal plane support.
> 
> I'm wondering if anybody here knows whether this a legit approach for a
> compositor's DRM backend to take?

Hi,

I was aware of tiled monitors that need two connectors driven by two
CRTCs to cover the whole display, but that sounds new to me.
Libweston/DRM still doesn't support tiled monitors.

What a compositor's DRM-backend can or should do must be generic. It
cannot be driver or hardware dependent, so handling your case specially
in userspace would need KMS UAPI to communicate the need in the first
place. (There is no shared library for "KMS userspace drivers", yet at
least.)

I am not aware of any KMS UAPI that would indicate the need to use two
primary planes in a specific configuration for a specific video mode.
I'm saying two primary planes, because that is the only way I can see
this situation even hinted at userspace with the current UAPI. I also
don't know if multiple primary planes is allowed, but it certainly is
not expected by userspace, so userspace can't make use of it as is.

The idea that comes to my mind is to hide all the details in the
driver. Expose just one primary plane as usual, and if the video mode
and FB actually need two scanout units, then steal one under the hood
in the driver. If that makes another KMS plane (exposed to userspace)
unusable, that is fine. Userspace with atomic modesetting needs to be
checking with TEST_ONLY to see if a configuration is possible, and will
fall back to something else.

For legacy modesetting I guess you would need to pick between
supporting the really large video modes vs. exposing all planes. But
that's a no-brainer, since the legacy API for planes is practically
unusable. Then again, I don't know if the kernel DRM core allows you to
make such distinction.

Btw. AFAIK there is nothing wrong with using the exact same FB on
multiple planes simultaneously.


Thanks,
pq