Hi Keith, On Sat, 5 Oct 2019 at 17:16, Keith Packard <keithp@xxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
