liboutput: thoughts about shared library on top of DRM/KMS

[Daniel Stone]

Hi Keith,

On Sat, 5 Oct 2019 at 17:16, Keith Packard <keithp at keithp.com> wrote:
> During XDC this year, we heard a few presentations and had a lot of
> hallway talk about sharing code for driving DRM/KMS for display.

Definitely. That would be great.

> I think the general consensus is that there is enough shared
> functionality between all of the various DRM/KMS clients that we can
> start thinking about building a library that deals with the complexity
> of DRM/KMS and can help take full advantage of the hardware.

Yeeeessss. Ish.

There are definitely a few annoying problems which we should have
common resolution for. I'm thinking of:
  - libliftoff's mandate of solving the views -> planes conundrum;
it's a ton of work to do properly, is extremely easy to get wrong, and
will ultimately require platform-specific tweaks as well
  - similarly, working backwards from 'I want to light these
connectors up' to determine the plane -> CRTC -> connector routing,
which also requires a mixture of brute force and platform-specific
tweaks - currently this is mostly just to handle asymmetric CRTC
capabilities (e.g. max clock), but is being complicated by the
requirement for merged CRTCs
  - EDID/CEA/etc parsing, which is not only tedious and sucks, but
requires a quirks database
  - sharing a mode-selection description language and semantics might
also be nice
  - parsing DRM properties - particularly enums - is painful enough
that Weston wrote its own internal wrapper around it
  - TTY handling :(

Having those as helper libraries would solve a _lot_ of issues Weston
has today. But pushing much more than that - thinking of rendering and
transforms in particular - is going to be actively harmful to us.
Given that we want to work on not just KMS, but nested-Wayland,
nested-X11, remote protocols like RDP/Waltham, and even mixed
local/remote setups where some outputs are KMS and others are at the
end of an RTSP stream, I'm going to need to implement most of this
stuff anyway.

Delegating everything to a big does-everything-KMS library means that
I'll just have to do it twice, and hope there isn't too much impedance
mismatch between the results. I also worry about both colour
management and timing: the users are going to have radically different
wants and requirements for those, and a one-size-fits-all API seems
like it would be tough to deal with.

I think there would be a load of value in starting with simple helpers
which can be used independently of any larger scheme, tackling that
list above. Most of them have good prior art: libliftoff is working
from Weston's plane-assignment code, Mutter has pretty good CRTC <->
connector routing IIRC, EDID parsing is best in the X server, DRM
properties are probably best done in either Weston or kmscube
(depending on the enum vs. string efficiency tradeoff), and TTY
handling is probably most robust in the X server.

If I was starting a compositor from scratch then I'd probably think
pretty hard about a does-everything-for-you library, but with
libweston already existing, it's a much harder sell tbh.

Cheers,
Daniel