-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multi EIS in remote desktop and PW stream integration #2
base: main
Are you sure you want to change the base?
Conversation
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.
eis_region_get_y (region) == y && | ||
eis_region_get_width (region) == width && | ||
eis_region_get_height (region) == height) | ||
return TRUE; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wondering if it's worth checking the mapping ID matches too and g_warn
if not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It won't match, because it may happen when some user would "share" two mirrored monitors in two different streams. Useless? yes. Theoretically possible? yes. Maybe there is a more clever way to handle this, but can probably live with it for a bit.
No description provided.