On Mon, Jan 20, 2020 at 2:58 AM Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote:
On Fri, 17 Jan 2020 10:51:45 -0600
Matt Hoosier <matt.hoosier@xxxxxxxxx> 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 Pekka; thanks for the reply.
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.
Just to double-check: I think we're still talking here about universal-plane mode, so we only mean "primary plane" in an informal sense? This problem would crop up on any attempt to attach a huge framebuffer to a single plane (whether it happened to be the bottom z-sorted one or a something used as an overlay).
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.
I think that's about the only approach that would make sense. Who would be a good person to sanity-check that with? Daniel V? Daniel S?
I suppose in principle that if this is a valid corner-case of the KMS api, then maybe it wouldn't be wrong to enhance compositors DRM backends to progressively attempt attaching more and more planes to scan a framebuffer if the drmModeAtomicCommit(DRM_MODE_ATOMIC_TEST_ONLY) fails for the base case. But whether anybody in the Weston world would want that patch is probably another story...
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
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
