Curtaining API / Force blanking displays

[Daniel Vetter]

On Sun, Apr 05, 2020 at 11:21:31AM +0300, Pekka Paalanen wrote:
> 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?

Yup, this should be done in something like systemd-logind, whose job it
already is to forcibly remove master rights and stuff like that. "I'm
going to take your display to blank it" is a very natural extension of
that.

Wrt actual screen grabbing part: We have minimal support for that, for
smooth/flicker free booting. But that assumes the old compositor has
ceased to access the driver already, there's 0 support for correctly
syncing access to buffers. So if you do that behind a compositor huge
chances that you race and read out black, when the user actually sees
seomthing ... Fixing that isn't possible without the cooperation of the
compositor and some real protocol. Essentially you need a nested
compositor, with maybe something like drm_lease thrown on top for a nice
fast-path for when the system compositor does not want to capture all the
frames.

Again the kernel isn't in that business, that's userspace's job.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch