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

[Marius-cristian Vlad]

On Fri, 2018-08-24 at 11:58 +0200, Philipp Zabel wrote:
> 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.

Got it. Will give it a test and see how it goes.


> 
> regards
> Philipp