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 ;).

[khurshid-alam]

Blame RH for forcing immature technology on general linux community. Wayland, systemd, pulseaudio, telepathy we have seen it all.

Note: Ubuntu's mir project can already do that and more.

[Sunderland93]

PipeWire is the solution https://github.com/wtay/pipewire

[MaartenBaert]

While interesting, I don't see how that would help resolve perceived security concerns.

Edit: Presumably you are referring to this talk. If GNOME is indeed going to add this, that's a step in the right direction, but that doesn't really solve the problem for other Wayland compositors.

I'm a bit worried that this thing is going the same way as PulseAudio. It's massively overcomplicated for what it actually needs to do for me. It just needs to pass video frames from one application to another - I do this already with GLInject and it's really not that difficult. But for some reason it apparently has an entire plugin architecture. It also does audio apparently (as if we didn't have enough audio APIs yet - what I need is an API that actually works reliably, not one with a million crazy features). It depends on GStreamer for reasons that aren't clear to me. All this complexity greatly increases the number of bugs, as PulseAudio has demonstrated. And video is harder than audio, not easier.

[Sunderland93]

@MaartenBaert PipeWire is not only for GNOME desktop. It is the replace of PulseAudio, JACK and GStreamer (of course with backwards compatibility with them), with support for video streams and possibilities needed by Flatpak and Wayland.

[MaartenBaert]

A pretty ambitious project. It could be great, but I'm still skeptical. Just because it's not GNOME-only doesn't mean that the other desktop environments will add support for it any time soon. Just because it has all the necessary features doesn't mean that it will be robust and bug-free (see PulseAudio). We will see once it actually gets deployed.

[bepolymathe]

This is bad news for me.
Besides Wayland or Xorg, I have the black screen problem with both.
Thanks in any case for SSR that I used with happiness until now with ubuntu/kde...

[StripedMonkey]

Honestly I am curious how this is going to work out, at this point Ubuntu is using gnome which is defaulting to wayland. Mir is out of the way (since this issue was opened) as well.

Have the wayland team created an API for screen capturing that you can use yet Maarten?

[MaartenBaert]

I haven't really followed Wayland development. I think a simpler solution would be to create something like OpenGL recording specifically for Wayland. Since Wayland applications execute all drawing operations client-side, it should be relatively easy to capture a complete image and send it to SSR.

Of course this still won't help you if you want to record more than one application. For that I could try to apply OpenGL recording to the compositor itself, but since the compositor is already running when SSR is started, this is much more tricky.

[dog5tar]

Having the same issue: recorder video is black, mouse visible, sound OK.

Fedora release 27 (Twenty Seven)
GNOME:

<?xml` version="1.0" encoding="UTF-8"?>
<gnome-version>
 <platform>3</platform>
 <minor>26</minor>
 <micro>2</micro>
 <distributor>GNOME.Org</distributor>
 <date>2017-11-01</date>
</gnome-version>

Any resolution as of yet?

[ywarnier]

Same issue on Ubuntu 17.10 with Gnome 3.26.1

[ajepe]

No known solution yet

[glaubersm]

Will SSR support pipewire?
https://blogs.gnome.org/uraeus/2018/01/26/an-update-on-pipewire-the-multimedia-revolution-an-update/

[MaartenBaert]

@foxcpp Out of curiosity, what's the performance like? Is it comparable to X11 in terms of maximum frame rate?

[foxcpp]

@MaartenBaert, I can't get more than 40 FPS, however on X11 I can get up to ~100. I used wlr-screencopy extension, which is basically intended for screenshots, not for recording. Performance may be better with wlr-export-dmabuf extension. Perhaps I will try to use it instead when I will have some spare time.

[Sunderland93]

dmabuf-based solution for OBS Studio obsproject/obs-studio#1758

[umeklinks]

Hello, I don't know if you have fixed this bug but if you haven't let me help out because I ran into the same issue. Here's a solution for it, NOT REALLY A PERMANENT ONE but on the user side that will take you throughout the period of using your OS (I'm running on Fedora 30 and I equally encountered it on the Fedora 32 all fixed with this approach):

Your need to Configure Xorg as the default GNOME session. On your terminal open your custom.conf by typing this command sudo nano /etc/gdm/custom.conf and uncomment WaylandEnable=false if it's commented but must be set to false

Then, on the [daemon] section just under WaylandEnable=false add this line DefaultSession=gnome-xorg.desktop and save the file. Restart your system and try running your Screen Recorder program again.
Congratulations.

However, if nano command is not working please try installing it by running the command
sudo dnf install nano or sudo apt-get install nano whichever one works for you.

[glaubersm]

your link contains no fix.
SSR needs Wayland support.

[umeklinks]

your link contains no fix.
SSR needs Wayland support.

Alright thanks a lot. I just edited it to fix in the detail procedure to the solution.

[bugnano]

Today I read this blog post that fixed the Wayland issue on OBS Studio:

https://feaneron.com/2019/11/21/screencasting-with-obs-studio-on-wayland/

Maybe it could be used as an inspiration for SSR

[MaartenBaert]

They seem to make use of xdg-desktop-portal which is an API for sandboxed applications. I'm not sure whether this even applies to regular applications. It looks like PipeWire is also required (but not sufficient). I'm not sure how many desktop environments actually support this, since PipeWire is rather GNOME-focused. It may not be a complete solution but maybe it's useful for some users. I don't have time to implement this now though, maybe later.

[foxcpp]

xdg-desktop-portal API is implemented by KDE too: https://github.com/KDE/xdg-desktop-portal-kde

There was (is?) some ongoing work to implement it for wlroots-based compositors (e.g. sway): emersion/xdg-desktop-portal-wlr#1

[Sunderland93]

@MaartenBaert

They seem to make use of xdg-desktop-portal which is an API for sandboxed applications

Not only. It's common way to screengrabbing on Wayland (and X11 too)

since PipeWire is rather GNOME-focused

No, it's not related to GNOME

[troywweber7]

Looks like this is still an issue?

[mazulo]

I can confirm this is still an issue (it was working few weeks ago but today I just got this error) @troywweber7

[ghost]

same problem, I am using wayland

[europ]

FIX can be found in #565

[bugnano]

@europ #565 is not a fix for this issue. We cannot continue suggesting using xorg when the current direction of the Linux desktop is clearly Wayland, so we need to fix the issue in SSR, and not suggest workarounds that will not work in the long run.

[europ]

@bugnano not a problem.

so we need to fix the issue in SSR

When it is going to be fixed?

It was reported in 2016. Only this workaround could make it work for me. Please, share us some step-by-step fix that will work on wayland.

[jtojnar]

Please stop spamming here.

It is going to be fixed when someone finds time to implement a PipeWire support as suggested here: #431 (comment)

For now, you can only use the workaround you and many people before you noticed (run Xorg session) or try to contribute a PipeWire support.

Repeated questions about when this will be fixed or posting the same “solution” again and again is not productive so I suggest @MaartenBaert locks this issue (and #565) so only people with something to say (him) can post here.

[zippy-zebu]

We cannot continue suggesting using xorg when the current direction of the Linux desktop is clearly Wayland...

!!
Do you have any proof ? A few months back hacker-news posted a statistic which shows 99% Linux machines (both server & desktop) are still xorg. Bothering the developer to fix a issue for a display manager which nobody uses is just outrageous. It will happen when the PipeWire support lands and that is not happening anytime soon.

This issue needs to be closed all together.

Thank You.

[MaartenBaert]

I am planning to implement PipeWire support at some point, but it's a lot of work since it also requires significant GUI changes, a lot of the features that we have with X11 will probably be lost, OpenGL recording is still a problem and I'm not even sure whether PipeWire will solve the problem for all distros and desktop environments that use Wayland right now.

A lot of people are still using outdated systems, as a result it usually takes years before I can roll out new features to everyone. E.g. I know that about two years ago 30% of SSR users were still running the 32-bit version, despite the fact that almost any CPU sold during the last 10 years is 64-bit. Which is why I spent time implementing SIMD optimizations for 32-bit ...

So supporting the latest new APIs isn't a super high priority for me, I prefer to focus on stability. Even with PipeWire support I will likely continue to recommend X11 for stability reasons for a long time.

I also have to figure out how I can add support for PipeWire without pulling in another dependency that X11 users don't need. So it will get there eventually, but for now X11 is the way to go.

[Sunderland93]

I also have to figure out how I can add support for PipeWire without pulling in another dependency that X11 users don't need.

PipeWire with xdg-desktop-portal also works on X11 (and in particular Flatpak)

[umeklinks]

Hello, I don't know if you have fixed this bug but if you haven't let me help out because I ran into the same issue. Here's a solution for it, NOT REALLY A PERMANENT ONE but on the user side that will take you throughout the period of using your OS (I'm running on Fedora 30 and I equally encountered it on the Fedora 32 all fixed with this approach):

Your need to Configure Xorg as the default GNOME session. On your terminal open your custom.conf by typing this command sudo nano /etc/gdm/custom.conf and uncomment WaylandEnable=false if it's commented but must be set to false

Then, on the [daemon] section just under WaylandEnable=false add this line DefaultSession=gnome-xorg.desktop and save the file. Restart your system and try running your Screen Recorder program again.
Congratulations.

However, if nano command is not working please try installing it by running the command
sudo dnf install nano or sudo apt-get install nano whichever one works for you.

Currently, I did a fresh installation of the newly released Fedora 32, I had a video called that required me to share my screen, only to discover that it's recording a blank screen. I then downloaded SSR but still the same issue. Then I followed this same procedure I wrote last year and it fixed.

However, I discovered on the Fedora 32 Windowing System changed to X11 instead of Wayland after this procedure. But I can now record my screen.

[engineervix]

Hello, I don't know if you have fixed this bug but if you haven't let me help out because I ran into the same issue. Here's a solution for it, NOT REALLY A PERMANENT ONE but on the user side that will take you throughout the period of using your OS (I'm running on Fedora 30 and I equally encountered it on the Fedora 32 all fixed with this approach):
Your need to Configure Xorg as the default GNOME session. On your terminal open your custom.conf by typing this command sudo nano /etc/gdm/custom.conf and uncomment WaylandEnable=false if it's commented but must be set to false
Then, on the [daemon] section just under WaylandEnable=false add this line DefaultSession=gnome-xorg.desktop and save the file. Restart your system and try running your Screen Recorder program again.
Congratulations.
However, if nano command is not working please try installing it by running the command
sudo dnf install nano or sudo apt-get install nano whichever one works for you.

Currently, I did a fresh installation of the newly released Fedora 32, I had a video called that required me to share my screen, only to discover that it's recording a blank screen. I then downloaded SSR but still the same issue. Then I followed this same procedure I wrote last year and it fixed.

However, I discovered on the Fedora 32 Windowing System changed to X11 instead of Wayland after this procedure. But I can now record my screen.

I can also confirm that this worked on my Fedora 32 installation.

[bugnano]

Please stop spamming here.

It is going to be fixed when someone finds time to implement a PipeWire support as suggested here: #431 (comment)

For now, you can only use the workaround you and many people before you noticed (run Xorg session) or try to contribute a PipeWire support.

Repeated questions about when this will be fixed or posting the same “solution” again and again is not productive so I suggest @MaartenBaert locks this issue (and #565) so only people with something to say (him) can post here.

I agree with @jtojnar
Please, lock this issue, as the roadmap to fix this issue is clear, and any further comment in this thread brings in nothing of value.