On Mon, Jan 20, 2020 at 2:58 AM Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Fri, 17 Jan 2020 10:51:45 -0600 > Matt Hoosier <matt.hoos...@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 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
