Screen recording on Wayland

With Wayland being the default now in Ubuntu 17.10 my Snap of my small screen recording utility Peek became unusable for users installing it from the Ubuntu Store, expecting it to work out of the box.

Is there any work done on getting screen recording working from inside the Sandbox? I know Pipewire might become the goto solution in the future, but is there anything usable today?

For e.g. Flatpak I easily can expose the Gnome Shell DBus service org.gnome.Shell.Screencast, but one cannot open up the Snap sandbox in a similar way.

See also related discussion on https://github.com/phw/peek/issues/245

1 Like

Can you expand on this? Is the recording application supposed to bind to this DBus interface as a server or is this the DBus api your application would use to record? Either way, this sounds like it needs to be a new interface.

GNOME Shell provides this interface. The point is that in Flatpak it is easy to open up the sandbox for your app to allow access to this interface, whereas Snap does not allow this (*). So yes, Snap would need to provide some kind of interface to allow access to the screen. Hence my question whether there is already some work in progress or talk about such an interface.


(*) As far as I have understood that is mainly a difference in how Flatpak and Snap approach the sandboxing security: Both projects envision a system, where all apps are sandboxed and given access only in a secuire and controlled way to external resources. But while Flatpak tries to be usable right now and allows quite some flexibility for individual apps to poke holes into the sandbox, in the hope they can tighten this up later, Snap maintains a security first approach where only selected interfaces that are considered save enough now are allowed.

I’ve added this interface to the roadmap.

I’d also like to be clear that snaps are meant to be usable right now too and the snap system also allows a lot of flexibility for applications to use different resources on the system, though what is exposed will sometimes be different from other sandboxing mechanisms where access to those resources may be automatic or based on user choice depending on the request. In this particular case, the only reason why the interface isn’t available today is because no one expressed a need for it until now.

It wasn’t clear (to me) that Peek understands how to use org.gnome.Shell.Screencast. Can you comment? If it does we can use Peek as a test case when developing the interface.

Actually I am not sure org.gnome.Shell.Screencast is necesarily the right basis for an interface. I just use it in Peek because it is easily available and it was the only existing way to implement screencasting in Gnome on Wayland.

But AFAIK it is mainly an intermediary solution Gnome developers put into place to support screen recording in Wayland. To my knowledge they aim to move to a more standardized interface, which is suited for sandboxed applications and takes care of security, based on pipewire.

I am fine with every interface that allows screen recording and satisfies Peek’s requirements. But right now one is mostly out of luck doing this on Wayland with sandboxing technology.

See also related discussions at:

Related implementation for Flatpak as a screencast portal: https://github.com/flatpak/xdg-desktop-portal/pull/122/files

@phw has now dropped snap support from Peek because

The current Snap sandboxing does not allow Peek to access any screen recording capability in current Wayland implementations

:frowning:

(Among other issues)

This is still in backlog. Note that classic confinement is available to people who need to move faster than what interfaces (and the prioritized roadmap) currently allows.

@phw - I’m not sure if classic confinement is of interest to you. I suspect snapd 2.33 will allow your snap to work in strict mode.

Philipp said

I tried classic confinement for Peek for a while, but switched back to standard confinement after issues here.

Source

Philipp uses Arch and snapd on Arch is not quite as seamless as it should be (because of Arch maintainers moving it out of the main repos and disallowing the package from symlinking /snap by default)

I think we need to make Snap more cross-platform oriented, in order to full-fill the purpose of snap (one package for all) :slightly_smiling_face: and yeah Theme issue should be resolved, it’s so annoying :frowning:

Note that @mborzecki is working on making sure Arch is now and continues to be fully supported. If there are specific things separate from this topic that still aren’t working on Arch, please create new topics so they can be properly tracked, prioritized and addressed. Thanks!

2 Likes

Actually, this snap was granted use of classic confinement last July. Regardless, I’m looking at this interface now if you want to revisit for 2.33.

Ok, added another topic. Turns out I wasn’t entirely right that it doesn’t work at all, but still doesn’t look right.

Yes, I tried using classic confinement. I had some issues with this, so I turned back to strict again. Mainly back then it was not supported on all platforms, e.g. Arch (where it should actually work now) and it required an additional flag for installation. Is the latter handled automatically by the software center?

Anyway, for now I have canceled any support for snap packages. It turns out that while Peek itself is a very simple tool, it’s requirements regarding sandboxing aren’t. I don’t have plans to invest any more time into this, I just can’t handle supporting this anymore. I am happy to revisit this once snapd and the surrounding infrastructure have matured a bit more, but it was too much a time sink in the past and the latest results of a Peek snap package where still unsatisfying.

Having said this, the support by various members of the snap team was great.

Regardless, I’m looking at this interface now if you want to revisit for 2.33.

One last word: I had a look at the interfaces proposed for Flatpak, and it looks like it won’t really do for Peek. Peek’s UI is really about providing the user a simple way to select a screen region to record, that means it uses the position and size of Peek’s window itself to determine what to record. The proposed interface seems to move the selection of the screen to record to a portal specific UI.

Maybe Peek is just not possible in the new sandboxed Wayland world :frowning:

Peek is dead, long live OBS? Is there not a bug you can file somewhere to try and challenge some design (on Wayland’s side?) around this?