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, 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
Attachment:
pgpWKdftf4g8x.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
