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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel