Hi Nicholas! On Tuesday, August 24th, 2021 at 16:56, Kazlauskas, Nicholas <nicholas.kazlauskas@xxxxxxx> wrote: > It's easiest to under the hardware cursor as being constrained within > the DRM plane specifications. Each DRM plane maps to 1 (or 2) hardware > pipes and the cursor has to be drawn along with it. The cursor will > inherit the scale, bounds, and color management associated with the > underlying pipes. Ah, I see. So the reason why we need to draw the cursor twice is to accomodate for the case where it's visible on both the primary and overlay planes, e.g. ┌────────────────────────────┐ │Primary │ │ │ │ │ │ ┌───────┐ │ │ │Cursor │ │ │ │ │ │ │ │ ┌───┼────────┐ │ │ └───┼───┘ │ │ │ │ │ │ │ │ │ │ │ │ Overlay│ │ │ └────────────┘ │ │ │ └────────────────────────────┘ Is that right? In the case where the cursor only intersects a single plane (either primary or overlay) we need to draw it once only. Since some KMS user-space (ChromeOS) uses the non-atomic cursor with the rest of the atomic API, we need to always ensure that the cursor can be enabled at any time, even if it's currently disabled. > Correct me if I'm wrong, but I think your usecase [1] falls under the > category where: > 1. Primary plane covers entire screen > 2. Overlay plane does not cover the entire screen > 3. Overlay plane is scaled (1) and (2) are correct, but (3) is not. My overlay plane isn't scaled, but my primary plane may be. That doesn't change the outcome: the unscaled cursor can be painted onto the overlay pipe, but not onto the primary pipe. > I don't remember if DRM has a requirement that the cursor plane must be > topmost, but we can't enable [1] as long as it is. KMS has a standard "zpos" property [1], which may be mutable. So we could in theory set an immutable "zpos" for the primary plane and overlay plane, and allow user-space to change the "zpos" of the cursor plane to move it in-between. But for my use-case, I need the cursor plane to be painted on top of the overlay, so it'd only be useful when the cursor doesn't intersect the overlay. [1]: https://drmdb.emersion.fr/properties/4008636142/zpos > 1. You want to save power: > > You will burn additional power for the overlay pipe. > > But you will save power in use cases like video playback - where the > decoder produces the framebuffer and we can avoid a shader composited > copy with its associated GFX engine overhead and memory traffic. > > 2. You want more performance: > > You will burn additional power for the overlay pipe. > > On bandwidth constrained systems you can save significant memory > bandwidth by avoiding the shader composition by allowing for direct > scanout of game or other application buffers. > > Your usecase [1] falls under this category, but as an aside I discourage > trying to design usecases where the compositor requires the overlay for > functional purposes. My use-case actually falls under both (1) and (2). We want to leave as much bandwidth as possible for the game to use. We want to save power because we're running on battery. We don't _require_ KMS planes to run, we have a fallback composition path which uses the compute queue. But we want to do as much as possible to use KMS planes.
