On Fri, 3 Apr 2020 12:56:33 -0700 Erik Jensen <rkjnsn@xxxxxxxxxx> 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
Attachment:
pgpMJg1aZF1Du.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
