Curtaining API / Force blanking displays

[Erik Jensen]

Thanks, all for the thorough answers, even if they weren't necessarily
the answers I was hoping for. It sounds like a "system compositor"
would definitely be the right place for a remote desktop solution,
with the unfortunate caveat of not currently existing. :) (At least,
the most recent mention I can find of folks working on the concept is
from 2013.)

I'll probably make a post to wayland-devel to gather thoughts about
how to best proceed. With the current trend toward assuming at most
one graphical session for each user, the current approach of spinning
up a separate Xvfb instance is becoming more broken more often, so
hopefully there's a solution to be found somewhere in the stack.

On Tue, Apr 7, 2020 at 1:23 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > > With uinput, you will be having fun issues trying to guess what
> > > keymaps the display server and apps might be using, since you need
> > > to know that to be able to manufacture the right evdev keycodes
> > > that will be translated into the keysyms you actually wanted.
> > > Keymaps can change dynamically, too.
> >
> > This isn't a concern to us, as we plan to transmit keycodes and leave
> > the keyboard mapping to the remote machine.
>
> Why would that not have exactly the problem I mentioned?
>
> Do you expect your users to figure out what keymap is in effect in the
> server, and manually configure the same in your remote client, then hope
> it doesn't change?
>
> Keymaps can be user customised as well, so maybe your client does not
> even have a matching one.
>
> Or maybe you require users to reconfigure their desktop keymap to match
> the remote viewer?

The model used by Chrome Remote Desktop is to operate as if the local
keyboard were connected to the remote machine directly. I.e., the user
manages the keyboard layout on the remote machine while connected, and
the local layout is ignored. Our most common use case on Linux is a
user connecting remotely to their own workstation, and this seems to
work fairly well, and runs into fewer cross-platform issues than
trying to guess what the user means.