Curtaining API / Force blanking displays

[Pekka Paalanen]

On Fri, 3 Apr 2020 12:56:33 -0700
Erik Jensen <rkjnsn at google.com> wrote:

> First off, apologies if the functionality described already exists and I
> just failed to find it, or if this isn't the correct venue for this
> discussion. If so, pointers to the correct location would be appreciated.
> 
> I'm currently looking into the feasibility of developing a remote access
> tool using kernel-level interfaces (e.g., drmModeGetFB and uinput) to
> operate regardless of whether the user is using Xorg, a Wayland compositor,
> or even a text console (assuming KMS is in use).
> 
> One of the requirements, however, is the remote user is able to "curtain"
> their session in order to prevent individuals near the physical machine
> from watching their session. Imagine a user working from home and
> connecting to their workstation in a shared office space.
> 
> One possible solution I came up with would be a new kernel API to allow a
> privileged process other than the DRM-Master to request that all displays
> of a card be blanked or left in power saving mode. This wouldn't affect the
> ability of the DRM-Master to change modes and layout configuration, but no
> content would be visible on the physical displays until the curtaining
> process ended the curtain or exited.
> 
> Is this (a) a good approach to solving this issue, (b) an API that, if
> implemented, would be likely to be accepted into the kernel, and (c)
> something that would be feasible to implement given the current
> architecture? E.g., would it require changes in individual drivers, or
> could it be managed solely in driver-independent kernel code?
> 
> I'm new to DRI development, so if it is something that folks would be open
> to having, pointers to a good part of the code to look at to start
> implementing such a feature would be appreciated.

Hi,

I have heard of such a screen scraper already existing, maybe Simon
remembers where one is?

Personally I am very much against the whole idea:

Screen scraping like that will have big problems trying to a)
synchronize to the display updates correctly (was the screen
updated, did you get old or new frame, and you have to poll rather
than be notified), and b) synchronizing framebuffer reads vs.
writes (is the display server re-using the buffer when you are
still reading it). You also get to handle each KMS plane
individually.

You have to adapt to what the display server does and you have no
way to negotiate better configurations. The framebuffers could be
tiled and/or compressed, and quite likely are the kind of memory
that is very slow to read by CPU, at least directly.

It obviously needs elevated privileges, because you are stealing
data behind the display server's back. Then you are feeding it
through network.

The curtaining goes against the policy that the current DRM master
is in full control of the display. It also means the kernel has to
lie to the DRM master to make the display server unaware of the
funny business, and I don't like that at all.

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.

I believe it would much better to cooperate with display servers
than trying to bypass and fool them. Maybe look towards Pipewire at
least for the screen capturing API?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20200405/381f04cc/attachment.sig>