reis::eis::device

Struct Device

pub struct Device(/* private fields */);

Implementations§

source §

impl Device

source

pub fn destroyed(&self, serial: u32)

This device has been removed and a client should release all associated resources.

This ei_device object will be destroyed by the EIS implementation immmediately after after this event is sent and as such the client must not attempt to use it after that point.

source

pub fn name(&self, name: &str)

The name of this device, if any. This event is optional and sent once immediately after object creation.

It is a protocol violation to send this event after the ei_device.done event.

source

pub fn device_type(&self, device_type: DeviceType)

The device type, one of virtual or physical.

Devices of type ei_device.device_type.physical are supported only clients of type ei_handshake.context_type.receiver.

This event is sent once immediately after object creation. It is a protocol violation to send this event after the ei_device.done event.

source

pub fn dimensions(&self, width: u32, height: u32)

The device dimensions in mm. This event is optional and sent once immediately after object creation.

This event is only sent for devices of ei_device.device_type.physical.

It is a protocol violation to send this event after the ei_device.done event.

source

pub fn region( &self, offset_x: u32, offset_y: u32, width: u32, hight: u32, scale: f32, )

Notifies the client of one region. The number of regions is constant for a device and all regions are announced immediately after object creation.

A region is rectangular and defined by an x/y offset and a width and a height. A region defines the area on an EIS desktop layout that is accessible by this device - this region may not be the full area of the desktop. Input events may only be sent for points within the regions.

The use of regions is private to the EIS compositor and coordinates may not match the size of the actual desktop. For example, a compositor may set a 1920x1080 region to represent a 4K monitor and transparently map input events into the respective true pixels.

Absolute devices may have different regions, it is up to the libei client to send events through the correct device to target the right pixel. For example, a dual-head setup my have two absolute devices, the first with a zero offset region spanning the left screen, the second with a nonzero offset spanning the right screen.

The physical scale denotes a constant multiplication factor that needs to be applied to any relative movement on this region for that movement to match the same physical movement on another region.

It is an EIS implementation bug to advertise the touch and/or absolute pointer capability on a device_type.virtual device without advertising an ei_region for this device.

This event is optional and sent immediately after object creation. Where a device has multiple regions, this event is sent once for each region. It is a protocol violation to send this event after the ei_device.done event.

Note: the fourth argument (‘hight’) was misspelled when the protocol was declared stable but changing the name is an API breaking change.

source

pub fn interface<InterfaceName: Interface>(&self, version: u32) -> InterfaceName

Notification that a new device has a sub-interface.

This event may be sent for the following interfaces:

“ei_pointer”
“ei_pointer_absolute”
“ei_scroll”
“ei_button”
“ei_keyboard”
“ei_touchscreen” The interface version is equal or less to the client-supported version in ei_handshake.interface_version for the respective interface.

It is a protocol violation to send a notification for an interface that the client has not bound to with ei_seat.bind.

This event is optional and sent immediately after object creation and at most once per interface. It is a protocol violation to send this event after the ei_device.done event.

source

pub fn done(&self)

Notification that the initial burst of events is complete and the client can set up this device now.

It is a protocol violation to send this event more than once per device.

source

pub fn resumed(&self, serial: u32)

Notification that the device has been resumed by the EIS implementation and (depending on the ei_handshake.context_type) the client may request ei_device.start_emulating or the EIS implementation may ei_device.start_emulating events.

It is a client bug to request emulation of events on a device that is not resumed. The EIS implementation may silently discard such events.

A newly advertised device is in the ei_device.paused state.

source

pub fn paused(&self, serial: u32)

Notification that the device has been paused by the EIS implementation and no futher events will be accepted on this device until it is resumed again.

For devices of ei_device_setup.context_type sender, the client thus does not need to request ei_device.stop_emulating and may request ei_device.start_emulating after a subsequent ei_device.resumed.

For devices of ei_device_setup.context_type receiver and where the EIS implementation did not send a ei_device.stop_emulating prior to this event, the device may send a ei_device.start_emulating event after a subsequent ei_device.resumed event.

Pausing a device resets the logical state of the device to neutral. This includes:

any buttons or keys logically down are released
any modifiers logically down are released
any touches logically down are released

It is a client bug to request emulation of events on a device that is not resumed. The EIS implementation may silently discard such events.

A newly advertised device is in the ei_device.paused state.

source

pub fn start_emulating(&self, serial: u32, sequence: u32)

See the ei_device.start_emulating request for details.

It is a protocol violation to send this event for a client of an ei_handshake.context_type other than receiver.

source

pub fn stop_emulating(&self, serial: u32)

See the ei_device.stop_emulating request for details.

It is a protocol violation to send this event for a client of an ei_handshake.context_type other than receiver.

source

pub fn frame(&self, serial: u32, timestamp: u64)

See the ei_device.frame request for details.

It is a protocol violation to send this event for a client of an ei_handshake.context_type other than receiver.

source

pub fn region_mapping_id(&self, mapping_id: &str)

Notifies the client that the region specified in the next ei_device.region event is to be assigned the given mapping_id.

This ID can be used by the client to identify an external resource that has a relationship with this region. For example the client may receive a data stream with the video data that this region represents. By attaching the same identifier to the data stream and this region the EIS implementation can inform the client that the video data stream and the region represent paired data.

This event is optional and sent immediately after object creation but before the corresponding ei_device.region event. Where a device has multiple regions, this event may be sent zero or one time for each region. It is a protocol violation to send this event after the ei_device.done event or to send this event without a corresponding following ei_device.region event.