As you know, this problem has been solved by making both screen sharing and remote control part of the xdg-desktop-portal API family. The main reason for this is that the problems they introduce that needs solving are fundamentally different, and the needed solutions will likely be different too.įor example, when a user shares the screen, they are already by the computer, and there should be no way possible for an application to taking over the control of or share the content the system, without the user having explicit control. Right now, there is no complete story of how actual remote login should work, in contrast to what you have discovered already works rather well: sharing your screen. Would love to hear thoughts from the community about the best way forward. I believe APIs can also allow Win32 apps to capture a window/screen without user interaction. Looking at how other software/systems are supporting screen capture/remote desktop, we see wlroots/sway allows for configuring the output screen to capture in a config file. Is it reasonable to extend the stream restoration support to work for remote desktop sessions as well as pre-populating the permission store to allow remote desktop session (so that user intervention can be avoided)? Also, would pre-populating the permission store work for system installation of CRD or would only work for flatpak/sandboxed version of the app? Is there a secure way to bypass the dialog/prompt selectively for apps? There seems to be recent support for restoring the capture streams (if persistence was demanded previously by the user) using flatpak permission store: but remembering streams for remote desktop session is explicitly disallowed in the portal frontend ( though this doesn’t seem to be GNOME specific). I would like to hear ideas from the GNOME community about how to best support the latter use case for remote desktop. accessing their work computer from home). to get help from IT) but it is less than ideal for a user who is trying to access their own machine remotely (e.g. Though this workflow would make perfect sense when a user is directly connected to the machine and is allowing someone remote to take control (e.g. While experimenting with remote desktop APIs, I see that for enhanced security, an interactive dialog (relevant code: ) is always presented to the user to select sources/devices they want to allow to be remote controlled. CRD would be leveraging remote desktop APIs (along with screencast) as exposed by xdg-desktop-portal. I am looking into supporting CRD for GNOME/wayland. Also, another member mentioned that there is a non-interactive/password driven option already - feel free to provide pointers for it, if that is the case.) (Cross posting her from the desktop mailing list since a helpful community member mentioned that people are not active on mailing list.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |