<div dir="ltr"><div dir="ltr">On Mon, Jan 20, 2020 at 2:58 AM Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 17 Jan 2020 10:51:45 -0600<br>
Matt Hoosier <<a href="mailto:matt.hoosier@gmail.com" target="_blank">matt.hoosier@gmail.com</a>> wrote:<br>
<br>
> Hi all,<br>
> <br>
> I'm confronting a situation where the hardware with which I work is capable<br>
> of driving connectors at 4K or 8K, but doing so requires bonding the<br>
> scanning of multiple planes together.<br>
> <br>
> The scenario is that you'd have a big primary framebuffer whose size is too<br>
> large for an individual hardware scanning pipeline on the display<br>
> controller to traverse within its maximum allowed clock rate.<br>
> <br>
> The hardware supplier's approach is to assign multiple planes, which in the<br>
> KMS driver map to hardware scanning pipelines, to each be responsible for<br>
> scanning a smaller section of the framebuffer. The planes are all assigned<br>
> to the same CRTC, and in concert with each other they cover the whole area<br>
> of the framebuffer and CRTC.<br>
> <br>
> This sounds a little bit wild to me. I hadn't been aware it's even legal to<br>
> have more than one plane treated a the source of scanout for a single<br>
> framebuffer. Maybe that distinction isn't really relevant nowadays with<br>
> universal plane support.<br>
> <br>
> I'm wondering if anybody here knows whether this a legit approach for a<br>
> compositor's DRM backend to take?<br></blockquote><div><br></div><div>Hi Pekka; thanks for the reply.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Hi,<br>
<br>
I was aware of tiled monitors that need two connectors driven by two<br>
CRTCs to cover the whole display, but that sounds new to me.<br>
Libweston/DRM still doesn't support tiled monitors.<br>
<br>
What a compositor's DRM-backend can or should do must be generic. It<br>
cannot be driver or hardware dependent, so handling your case specially<br>
in userspace would need KMS UAPI to communicate the need in the first<br>
place. (There is no shared library for "KMS userspace drivers", yet at<br>
least.)<br>
<br>
I am not aware of any KMS UAPI that would indicate the need to use two<br>
primary planes in a specific configuration for a specific video mode.<br>
I'm saying two primary planes, because that is the only way I can see<br>
this situation even hinted at userspace with the current UAPI. I also<br>
don't know if multiple primary planes is allowed, but it certainly is<br>
not expected by userspace, so userspace can't make use of it as is.<br></blockquote><div><br></div><div>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). </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The idea that comes to my mind is to hide all the details in the<br>
driver. Expose just one primary plane as usual, and if the video mode<br>
and FB actually need two scanout units, then steal one under the hood<br>
in the driver. If that makes another KMS plane (exposed to userspace)<br>
unusable, that is fine. Userspace with atomic modesetting needs to be<br>
checking with TEST_ONLY to see if a configuration is possible, and will<br>
fall back to something else.<br></blockquote><div><br></div><div>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?</div><div><br></div><div>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(<span style="color:rgb(60,64,67);font-family:Roboto,arial,sans-serif;font-size:14px">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...</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
For legacy modesetting I guess you would need to pick between<br>
supporting the really large video modes vs. exposing all planes. But<br>
that's a no-brainer, since the legacy API for planes is practically<br>
unusable. Then again, I don't know if the kernel DRM core allows you to<br>
make such distinction.<br>
<br>
Btw. AFAIK there is nothing wrong with using the exact same FB on<br>
multiple planes simultaneously.<br>
<br>
<br>
Thanks,<br>
pq<br>
</blockquote></div></div>