Multi EIS in remote desktop and PW stream integration #2

This is more or less never used elsewhere, so don't start here.

How EIS will be used depends on its context, meaning we'll have multiple EIS contexts that expose different things. To prepare for this remove the global socket since that won't work with multiple contexts.

This means there will be an EIS context per session, which will enable per session devices and region.

The portal could limit access to certain device types, but this was not forwarded to the EIS context. Add a way to do this, and make use of it.

This will allow passing extra context to the configure function. Currently all NULL, but preparing for the future.

A MetaEisViewport represents an absolute region backend by e.g. a pointer device. There are two kinds: a standalone viewport, which corresponds to a viewport that has no neighbours, and a non-standalone, which represents a region of a global coordinate space. The reason for having non-standalone viewports is to allow to mirror the logical monitor layout of a desktop, while the standalone are meant to represent things that are not part of the logical monitor layout.

We already have the remote desktop session ID, and we'll soon need the actual remote desktop session in the screen cast session, so pass it on construction. The old screen cast type is set implicitly instead.

This means clients can disconnect signals without warnings being logged.

They are guaranteed to be unique per session, and never reused.

This will be used to describe a eis_region in a eis_device.

Sometimes it makes no sense to have a shared pointer device, for example when they have no set region occupying the global stage coordinate space. This applies to for example window screen cast based pointer device regions - they are always local to the window, and have no position. We do need shared absolute devices in some cases though, primarily multi-head remote desktop, where it must be possible to keep a button reliably pressed when crossing monitors that have their own corresponding regions. To handle this, outsource all this policy to the one who drives the emulated input devices. Remote desktop sessions where the screen casts correspond to specific monitors (physical or virtual), we need to make sure they map to the stage coordinate space, while for window screencast or area screencasts, we create standalone absolute pointer devices with a single region each.

g_error() is fatal, but EIS errors are not necessarily that.

If we're a input-only remote desktop session, create libei regions on an absolute pointer device corresponding to all logical monitors. This allows absolute pointer motions without screen casting.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Multi EIS in remote desktop and PW stream integration #2

Multi EIS in remote desktop and PW stream integration #2

Commits on Aug 30, 2023

Multi EIS in remote desktop and PW stream integration #2

Are you sure you want to change the base?

Multi EIS in remote desktop and PW stream integration #2

Commits on Aug 30, 2023