#[non_exhaustive]pub enum Event {
Disconnected {
last_serial: u32,
reason: DisconnectReason,
explanation: String,
},
Seat {
seat: Seat,
},
InvalidObject {
last_serial: u32,
invalid_id: u64,
},
Ping {
ping: Pingpong,
},
}Variants (Non-exhaustive)§
This enum is marked as non-exhaustive
Disconnected
This event may be sent by the EIS implementation immediately before the client is disconnected. The last_serial argument is set to the last serial number used in a request by the client or zero if the client has not yet issued a request.
Where a client is disconnected by EIS on purpose, for example after a user interaction, the reason is disconnect_reason.disconnected (i.e. zero) and the explanation is NULL.
Where a client is disconnected due to some invalid request or other protocol error, the reason is one of disconnect_reason (i.e. nonzero) and explanation may contain a string explaining why. This string is intended to help debugging only and is not guaranteed to stay constant.
The ei_connection object will be destroyed by the
EIS implementation immediately after this event has been sent, a
client must not attempt to use it after that point.
There is no guarantee this event is sent - the connection may be closed without a disconnection event.
Fields
reason: DisconnectReasonthe reason for being disconnected
Seat
Notification that a new seat has been added.
A seat is a set of input devices that logically belong together.
This event is only sent if the client announced support for the
“ei_seat” interface in ei_handshake.interface_version.
The interface version is equal or less to the client-supported
version in ei_handshake.interface_version for the “ei_seat”
interface.
InvalidObject
Notification that an object ID used in an earlier request was invalid and does not exist.
This event is sent by the EIS implementation when an object that
does not exist as seen by the EIS implementation. The protocol is
asynchronous and this may occur e.g. when the EIS implementation
destroys an object at the same time as the client requests functionality
from that object. For example, an EIS implementation may send
ei_device.destroyed and destroy the device’s resources (and protocol object)
at the same time as the client attempts to ei_device.start_emulating
on that object.
It is the client’s responsibilty to unwind any state changes done to the object since the last successful message.
Ping
The ping event asks the client to emit the ‘done’ event
on the provided ei_pingpong object. Since requests are
handled in-order and events are delivered in-order, this can
be used as a synchronization point to ensure all previous requests
and the resulting events have been handled.
The object returned by this request must be destroyed by the ei client implementation after the callback is fired and as such the client must not attempt to use it after that point.
The callback_data in the resulting ei_pingpong.done request is
ignored by the EIS implementation.
Note that for a EIS implementation to use this request the client must
announce support for this interface in ei_handshake.interface_version. It is
a protocol violation to send this event to a client without the
“ei_pingpong” interface.