For most interfaces, the client announcing its supported version is
sufficient - the objects are all created server-side. For some
interfaces (ei_connection_setup and ei_callback right now) the client
needs to know the server-supported version.
So let's switch the current ei_connection_setup.version event (used to
negotiate ei_connection_setup's version) to a generic
`interface_version` event. This way our EIS implementation can
eventually send a version for ei_callback as well.
The Target was specific to libei/libeis, it resolved to "ei" or
"eis_client" depending on which component we were building. But that's
specific to our C implementation here, so let's push it into our C
implementation templates.
Leave the ei_callback as-is and instead add ei_pingpong for the same
thing initiated by the server. The interface is otherwise identical but
for the direction it is supposed to flow.
This reduces the possibility of a client accidentally sending a
request when it is supposed to handle an event or vice versa.
This is effectively the same as connection.sync, but goes the other way.
This adds the ei_callback.done request.
In libeis this is (currently) enforced immediately after sending the
connection object. Not required there and makes the code a bit messier
but this way we can ensure that any client library handles that part of
the code.
This event is to notify the client that an object used in a request was
unknown. This allows the client to work around race conditions like
binding to a seat that was removed.
This is currently the server-side only which is probably enough for now.
The only client-side created objects we have are the callbacks.
On the first run we extract the interfaces only, on the second run all
the rest. This allows us to pass the interface to the Argument where
appropriate.
This changes the initial connection negotiation to have the
ei_connection_setup as the pre-existing object id 0. Once the client has
sent all the data to set up the connection, the EIS implementation
replies with a new object ID that is the ei_connection protocol object,
i.e. the main object.
This allows for version negotiation of our main protocol object.
This allows us to have a device support multiple interfaces and evolve
those interfaces individually, e.g. add things to the keyboard interface
without having to bump the touchscreen interface.
Note that due to a name clash with the existing struct ei_touch public
API the protocol interface is named touchscreen.
