[PATCH wayland-protocols v3] unstable/drm-lease: DRM lease protocol support

[Philipp Zabel]

Hi Marius,

On Fri, 2018-08-24 at 09:21 +0000, Marius-cristian Vlad wrote:
> On Fri, 2018-08-24 at 10:57 +0200, Philipp Zabel wrote:
[...]
> > > yes, sending one event per connector is a good design, but see
> > > below if we actually might want to extend that to creating an
> > > object per connector with "per-attribute" events for pieces of
> > > information.
> > 
> > And object would allow handling both cases the same way when building
> > the lease request.
> 
> To make sure I understand this "object" leasing. Instead of advertising
> connectors this way:
> 
>     <event name="connector">
>       <description summary="advertise a leasable connector">
>         This event advertises a leasable connector. This allows the    
>            client to
>         choose which connector the compositor should lease. It can
> either
>         use connector name, monitor name, or if that's not sufficient
> to parse
>         EDID blob.
>       </description>
>       <arg name="conn_name" type="string" summary="connector name" />
>       <arg name="eisa_id" type="string" summary="eisa id"/>
>       <arg name="monitor_name" type="string" summary="monitor name"/>
>       <arg name="pnp_id" type="string" summary="pnp id"/>
>       <arg name="serial_num" type="string" summary="serial number"/>
>       <arg name="edid" type="array" summary="EDID blob"/>
>     </event>
> 
> We do something like this:
> 
>     <event name="connector_object">
>       <description summary="advertise a leasable connector">
>         This event advertises a leasable connector object.
>       </description>
>       <arg name="conn_obj" type="new_id"
> interface="zwp_kms_lease_connector_v1"
>       summary="the new temporary" />
>     </event>
> 
> 
> Then that interface is used to query info (like EDID/conn_name/monitor
> name)

Yes, that is my understanding as well.

I expect that for all currently known use cases the connector name (like
xdg_output.name) and the monitor vendor / product id / serial string
should be sufficient. Maybe the native resolution and refresh rate could
be useful as well.

I would suggest leaving the raw EDID out for now, a request for it can
be added later to zwp_kms_lease_connector_v1, if necessary. It won't be
possible to pass otentially huge complete EDIDs in an array argument.

> and using that information to ask/revoke the lease (based on
> either connector name, or based on EDID)?

I imagine that object to be passed to the lease request's add_connector
request directly:

  <interface name="zwp_kms_lease_request_v1">
    ...
    <request name="add_connector">
      <arg name="connector" type="object"
           interface="zwp_kms_lease_connector_v1"
           summary="a leasable connector to be added to the lease request"/>
    </request>
  </interface>

That way there is no need for separate requests "add_connector_by_name",
"add_connnector_by_vendor_product_serial" etc.

The same could potentially be done later with a "zwp_kms_lease_plane_v1"
object and "add_plane" request.

regards
Philipp