[PATCH wayland-protocols] RFC: unstable: DRM lease support

[Daniel Stone]

Hi Marius,

On 25 January 2018 at 10:17, Marius-cristian Vlad
<marius-cristian.vlad at nxp.com> wrote:
> > This interface seems a little idiosyncratic. Essentially, the client asks for creation of one lease (any lease), and the server returns it a lease with an ID. After that, the client destroys all the leases through the same interface. There are a couple of things I would suggest to improve this protocol, and make it more like other Wayland
> > protocols:
> >
> > Most Wayland protocols carry lots of small objects, since creating them is lightweight and straightforward. I think this protocol could be improved by doing something similar to the dmabuf protocol, which carries three objects: one global which is pretty much just for extension advertisement, one temporary object used in the creation of a buffer, and then the buffer object itself. Applied to leases, this would be a zwp_kms_lease_manager_v1 global which only had two requests: one destroy, and the other to create a wp_kms_lease_request object. zwp_kms_lease_request_v1 would be analagous to zwp_linux_dmabuf_params_v1: it would have requests to lease particular parts of the device (e.g. HDMI-2 output as well as two planes), and successful/failed events.
>
> [mvlad] I have some doubts that we can lease just parts of the DRM chain. drmModeCreateLease wants all the objects (planes,crtc,connector) to be passed in one go. Per my understanding we can lease the connector and the CRTC. The encoder for instance can't be leased. It used to, but after some re-designed of the lease it seemed no longer necessasry.

Right. What I meant is that we would build the list of objects
incrementally, rather than requiring them to be passed all at once,
e.g.:
req = zwp _kms_lease_manager_v1_get_request(mgr);
zwp_kms_lease_request_v1_add_output(req, output_hdmi1); /* adds CRTC +
connector + primary plane */
zwp_kms_lease_request_v1_add_plane(req); /* adds overlay plane */
lease = zwp_kms_lease_request_v1_create(req); /* only here is
drmModeCreateLease called */
zwp_kms_lease_request_v1_destroy(lease);

This would give a little bit more flexibility and avoids hardcoding
specific setups. It also makes it very clear what the life cycle is
for each stage.

> [mvlad] One more thing: I haven't tried leasing an overlay plane, only universal planes, so I'm not sure the kernel interface allows to do that, need to check that.

I think you mean 'scanout plane' here: 'universal planes' refers to
being able to treat scanout/cursor planes like overlay planes (i.e.
enumerate them through GetResources, and configure them outside of
SetCrtc/SetCursor/MoveCursor). I just checked now, and any kind of
plane can be leased.

There is one issue I spotted though: it's theoretically possible for
Weston to not enable universal planes but enable leasing; this will
result in us passing a plane ID of 0 (from our fake scanout plane) in
the lease request. Probably best to just not enable leasing if
universal planes isn't enabled; you'd have to have a very weird
contorted partial backport of libdrm/kernel to do that, but people
will absolutely try to do that, I'm sure. :)

Cheers,
Daniel