Hi! I’m with the Chrome Remote Desktop team at Google, and I have some time this year to work toward a standard API for persistent remote access under Wayland, especially important given future plans to remove X11 support. The current portals API for remote desktop is a good fit for remote support …

Hi Erik. About the draft Jonas did, that looks like what RemoteDesktop and Screencast portals do, but I don’t think that part covers starting and orchestrating headless sessions. Based on the current GNOME approach, I’ll try to explain in an abstraction level to see how things could be for any rem…

Thanks for the reply! [image] joantolo: The current RemoteDesktop and ScreenCast portals are enough for using a Wayland session. Even if session creation / curtaining is assumed to be handled by a different API analogous to the GDM RemoteDisplay API, there are three key pieces provided by @j…

I’m assuming things, since what I did was combining all the needed pieces on GNOME ecosystem to have the remote login. I haven’t played with portals [image] ErikJensen: Virtual monitors: The draft API has CreateVirtualMonitor, and Mutter has RecordVirtual. As far as I can tell, the Portal APIs …

Tangentially related: how much work would it be to expand the GDM changes to include support X11 sessions? (Xfce is our main DE of interest after GNOME, and still relies on X11.) The first part of the login seems like it would be the same (remote a login screen from GDM and prompt the user to kill …

sounds pretty straight forward to implement. mostly just small changes to gdm-x-session.c to start xvfb if its a headless session and gdm-sessions.c to make the x sessions not get filtered. it might need a small change or two elsewhere to make sure things are plumbed right

[image] joantolo: I think this might need to be addressed. Maybe add a method to get a restore_token, before calling Start. This way there’s an alternative way of getting permissions instead of using a dialog It sounds like KDE was also considering adding some kind of persistent token mechani…

Short term the best solution is to install an xdg autostart file in /usr/share/gdm/greeter/autostart/ i think for 47 we’re going to try to add systemd DynamicUser support to gdm so each greeter gets its own dynamically created user. at that point a service file should work

[image] ErikJensen: Remote assistance (supported well by the current Portal APIs) wants: Explicit user consent to share To allow the local user to select what to share To mirror the selected existing displays / windows Remote access wants: Persistent access To ensure the session is curtaine…

[image] joantolo: Hmm, I thought if a session service is started inside that session it can communicate with the dbus session daemon. At least, that’s what currently happens. Sorry, I meant having the session component as a systemd user service wouldn’t work for the greeter. Using the xdg aut…

Sorry, I meant having the session component as a systemd user service wouldn’t work for the greeter. Using the xdg autostart file as suggested by @halfline should work fine, since, as I understand it, that should result in the session component running as a descendant of dbus-run-session. Right a…

GNOME Discourse

Persistent remote desktop access API

Development

extensions

show post in topic

Home
Categories
Guidelines
Terms of Service
Privacy Policy

Powered by Discourse, best viewed with JavaScript enabled