Black screen on Wayland session

[alex285]

Obviously known bug, but I dont see another issue so I open it.

On Gnome Wayland session SSR only records the cursor, while the rest of the screen stays black. Nouveau drivers.

[Defman21]

This happens to me with open source drivers for AMD, but also my cursor has a strange trail.

[MaartenBaert]

Last time I checked Wayland didn't have an API for screen recording yet, but that was a long time ago. Maybe things have changed now. It's on the todo list, but not a very high priority right now.

[alex285]

@MaartenBaert GST for sure can screencast wayland. There is this extension that offers some options
https://github.com/iacopodeenosee/EasyScreenCast
but the screencast is very laggy, even on X session, so SSR is one way choice.

[MaartenBaert]

I haven't checked, but I guess they use a non-standard GNOME interface for this. I don't want to end up with different code for every possible window manager, I'm waiting for a standardized interface from the Wayland team.

[alflanagan]

You've probably seen this, but for anyone interested in Qt on Wayland:
https://wayland.freedesktop.org/qt5.html

[Sunderland93]

For example, Weston has screencast feature, activated by Super+R. So, Wayland has an screencast protocol.

[MaartenBaert]

No, to my knowledge it does not have a publicly accessible protocol. Also, Weston is the compositor, it doesn't need a protocol to record itself.

[Dynamic-Gravity]

So anyone running with latest GNOME or KDE won't be able to use this program?

[MaartenBaert]

Are any of the major distributions shipping with Wayland as default, or even as the only option?

I've had long discussions with the Wayland developers years ago about implementing screen capturing, global hotkeys, absolute positioning and other protocol features which they are still lacking. They aren't particularly enthusiastic about the idea, and the discussions got nowhere. They seem to feel that applications shouldn't actually need any of these features, therefore these features should not be used, and therefore implementing them is a bad idea. Someone has tried before to submit patches that allow absolute positioning - they got rejected. I'm pretty sure that the same thing would happen if I tried to submit patches that would allow screen capturing. The developers simply don't want these features.

They also had some legitimate but rather inconsistent/nonsensical security concerns. They were (rightly) worried that such a protocol feature could be abused to create keyloggers and other spyware, but at the same time they ignored that, at least under the current Linux permissions model, these keyloggers are already possible by other means. So obviously refusing to implement these features does not actually improve security. Some people simply refused to believe that this was a problem, so at that time I wrote my proof-of-concept Wayland keylogger.

I proposed that we should add these features now, and later, when a desktop environment with sandboxing capabilities actually shows up, simply disable those features for applications that don't have permissions to use them. Pretty much like Android does it. They didn't like that idea. They wanted something that was 'as secure as possible' even without sandboxing. I feel that this is a nonsensical stance since I had just proven that under their current model, security is not possible, so their nag screens asking the user to grant the application screen casting permissions would just be a nuisance that doesn't actually improve security - security theater, basically.

Since the entire discussion about security policy clearly wasn't getting anywhere, the developers decided to move all the policy-related stuff into 'Wayland Security Modules', which is pretty much the Wayland equivalent of 'Linux Security Modules' for the kernel. It means you can integrate Wayland with the security system of your choice without making Wayland dependent on that security system. It's a really good idea but it was also a lot of work. I was interested in writing screen capturing software, not dealing with security policies, so I decided to wait until the developers had decided how they wanted to handle their security, and meanwhile I just focused on SSR for X11 and OpenGL.

This was three years ago, and I haven't really been following Wayland development since then. AFAIK there is still no standardized screen capture interface, but it seems that the KDE people are now dealing with the same problem related to screenshots. It's still not a standardized solution and it's still not suitable for screen capture, but at least there is some progress.

For the time being, I think the most realistic option for me is to add Wayland capturing capabilities to GLInject. This is technically the ugly option but it doesn't require any permission or collaboration from the Wayland, GNOME, or KDE developers, and it will work for any application and any desktop environment. It's still a lot of work though, and I'm working on a number of other projects now instead of SSR. Since the number of people that run Wayland is still extremely small, it's not a high priority for me.

[Dynamic-Gravity]

That was an amazing reply. I'm pretty pissed off at the wayland people right now. I am using arch linux with custom 4.9 kernel, GNOME with wayland support and I have been trying for days to get screen capture stuff to work; as I want to get into content creation. I absolutely need screen capture and I just love you SSR. I am going to install Gentoo with just Xorg so I can actually start being productive. I think you have the right attitude towards the wayland devs. You got a patreon? I'd be happy to chip in.

[MaartenBaert]

Don't be too pissed off, the Wayland developers just have different goals. They want to make the protocol perfect - and perfection takes time. Meanwhile the users and desktop environment developers just want something that actually exists and works today, not in five years. This is also exactly why Canonical created Mir.

The actual window manager developers (Mutter, KWin, ...) are aware of these issues, and have added their own non-standard workarounds. As more users and applications try to move to Wayland, the core developers will eventually have to adapt and allow those features, otherwise it would hurt Wayland adoption. They don't deny that those features are useful, and there are a ton of other applications facing similar issues (notably accessibility software). I'm sure that these features will eventually appear. The developers just aren't in a hurry.

I don't take donations - what I need to continue work on SSR isn't money, it's time ;).