How to design a DRM KMS driver exposing 2D compositing?

[Pekka Paalanen]

On Mon, 11 Aug 2014 07:37:18 -0700
Matt Roper <matthew.d.roper at intel.com> wrote:

> On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote:
> > Hi,
> > 
> > there is some hardware than can do 2D compositing with an arbitrary
> > number of planes. I'm not sure what the absolute maximum number of
> > planes is, but for the discussion, let's say it is 100.
> > 
> > There are many complicated, dynamic constraints on how many, what size,
> > etc. planes can be used at once. A driver would be able to check those
> > before kicking the 2D compositing engine.
> > 
> > The 2D compositing engine in the best case (only few planes used) is
> > able to composite on the fly in scanout, just like the usual overlay
> > hardware blocks in CRTCs. When the composition complexity goes up, the
> > driver can fall back to compositing into a buffer rather than on the
> > fly in scanout. This fallback needs to be completely transparent to the
> > user space, implying only additional latency if anything.
> 
> Is your requirement that this needs to be transparent to all userspace
> or just transparent to your display server (e.g., Weston)?  I'm
> wondering whether it might be easier to write a libdrm interposer that
> intercepts any libdrm calls dealing with planes and exposes a bunch of
> additional "virtual" planes to the display server when queried.  When
> you submit an atomic ioctl, your interposer will figure out the best
> strategy to make that happen given the real hardware available on your
> system and will try to blend some of your excess buffers via whatever
> userspace API's are available (Cairo, GLES, OpenVG, etc.).  This would
> keep kernel complexity down and allow easier debugging and tuning.

That's an inventive proposition. ;-)

I would still need to design the kernel/user ABI for the HVS (the 2D
engine). As I am starting to believe, that the "non-real-time" use of
the HVS does not belong behind the KMS API, we might as well just do
things more properly, and expose it with a real user space API
eventually.


Thanks,
pq