Screensharing broken again (firefox, chrome, brave), only on laptop (i915 GPU)

[ppenguin]

Over the past year I have occasionally experienced screensharing to stop working after updates.
Similar issues have been frequently reported in the past, all I could find were ususally solved by using newer/older versions of hyprland and/or xdph.

On my i915 laptop (NixOS) this has been broken about 2 weeks, both using nixpkgs/nixos-unstable and using current git inputs for hyprland and xdph. On a desktop system with AMD GPU pretty much the same config is working.

I see the same on firefox, brave, chrome: black screen in the screen picker preview and black screen during sharing. Incidentally, I always get the screen number selection popup twice (but this also has been happening when screensharing was working, in fact for as long as I can remember).

I'm seeing the "usual errors" (in this case from sharing Jitsi Meet under Chrome):

96062:96725:0729/102051.182494:ERROR:egl_dmabuf.cc(608)] Failed to record frame: Error creating EGLImage - EGL_BAD_MATCH
[96062:96725:0729/102051.182521:ERROR:shared_screencast_stream.cc(938)] Dropping DMA-BUF modifier: 72057594037927940 and trying to renegotiate stream parameters
'loop->recurse > 0' failed at ../src/pipewire/thread-loop.c:425 pw_thread_loop_wait()
[96062:96872:0729/102100.026417:ERROR:egl_dmabuf.cc(608)] Failed to record frame: Error creating EGLImage - EGL_BAD_MATCH
[96062:96872:0729/102100.026449:ERROR:shared_screencast_stream.cc(938)] Dropping DMA-BUF modifier: 72057594037927940 and trying to renegotiate stream parameters
[96108:96150:0729/102100.036757:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
[96108:96150:0729/102100.247426:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
[96108:96150:0729/102100.454410:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
[96108:96150:0729/102100.661158:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
[96108:96150:0729/102100.868974:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
[96108:96150:0729/102101.075795:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
...

Since I tried current git and current nixpkgs/nixos-unstable, apparently this fix for a very similar issue didn't make a difference at all for me.

[cydiralis]

Can confirm that I am also experiencing this issue, though it seems to vary depending on what I'm using. Like I can successfully capture the screen in OBS but attempting to screenshare on weebcord results in the pictured image below. I have also included an image of obs working fine

[cydiralis]

This is with an amd gpu, I have no intel gpu based machines to test, however.

[DashieTM]

Somehow I am experiencing this issue only with my main monitor which is 3440x1440, choosing a secondary monitor works. This is the same for all browser based screensharing, obs works as expected however.

[ppenguin]

I have additionally tried the following:

• OBS works
• took pipewire, xdph and hyprland from current git (very painful on NixOS because a custom pipewire leads to re-compiling many huge deps which is very resource-intensive) => no improvement on jitsi screen sharing

I'm not sure whether OBS uses xdph or whether it might also use the gtk portal and how to check which one is used?

EDIT: BTW I've also tried with 10bits depth (in Hyprland monitor settings, which was published as a solution to a similar problem somewhere a few months ago) and at different resolutions/with/without external monitor (to cover @DashieTM 's case), but none made a difference.

[kito30]

I also have problem with screen sharing with vesktop, just pure blackscreen

[louiszn]

I have the same problem with firefox and vesktop

[alba4k]

Same here, screensharing works fine in OBS or discord via firefox, gives a black image in vesktop and telegram desktop

[ppenguin]

So many are using firefox, and for some it works and for others not? In that case does it depend on the web-app? Could the ones seeing this problem provide more info when post a "me too", such as:

1. do you have another computer with a very similar setup where it works?
2. System info: OS, GPU, hypr* version
3. Does any of the malfunctioning programs give a useful log? (possibly comparable to the above logged error)

@alba4k could you try with firefox on https://meet.jit.si/ whether that works too? That could tell us whether the web-app plays a role in all this?

[alba4k]

2. Arch, iris xe, everything -git

@ppenguin that website works, I think firefox in general is working fine for me

[lannibu]

In my case it's random.
In OBS i just have to select the screen over and over again until eventually it shows the screen.
The same thing with Vesktop.
And strangely the screenshare tends to work way often when I turn on a OBS virtual camera (I clearly don't know why).

Can't send logs srry.

My iGPU is Intel UHD Graphics 620

[BobVarioa]

I've been having much the same issue, but only when sharing my entire screen, but not for individual windows or regions.
I used this site to test, on both Firefox 129.0, and Chrome 126.0.6478.126. I also tested screenshare on Vesktop 1.5.3, also having the same caveat.
Though perplexingly, OBS works completely fine with no issues at all.

Also, here's some potentially useful commands

$ sudo lshw -C display
  *-display                 
       description: VGA compatible controller
       product: TigerLake-LP GT2 [Iris Xe Graphics]
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       logical name: /dev/fb0
       version: 01
       width: 64 bits
       clock: 33MHz
       capabilities: pciexpress msi pm vga_controller bus_master cap_list rom fb
       configuration: depth=32 driver=i915 latency=0 mode=1920x1080 resolution=1920,1080 visual=truecolor xres=1920 yres=1080
       resources: iomemory:600-5ff iomemory:400-3ff irq:197 memory:601e000000-601effffff memory:4000000000-400fffffff ioport:3000(size=64) memory:c0000-dffff memory:4010000000-4016ffffff memory:4020000000-40ffffffff
$ hyprctl systeminfo
Hyprland, built from branch main at commit b0a70f63e3865eaa77f0b78a04b230aa583bc95c  (wayland/compositor: drop pending buffer ref if synchronous).
Date: Tue Aug 6 10:08:22 2024
Tag: v0.41.2-169-gb0a70f63, commits: 5055

flags: (if any)


System Information:
System name: Linux
Node name: heracles
Release: 6.8.1-060801-generic
Version: #202403151937 SMP PREEMPT_DYNAMIC Fri Mar 15 19:52:22 UTC 2024


GPU information: 
0000:00:02.0 VGA compatible controller [0300]: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) (prog-if 00 [VGA controller])
	DeviceName: VGA


os-release: PRETTY_NAME="Ubuntu 24.04 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo


plugins:

[ppenguin]

For me it has suddenly been fixed, seemingly since v0.42.0? (I've been building rolling from git via NixOS flake inputs, but my laptop was broken for a few days due to a borked nvme (luckily my whole system is declarative so I'm up and running in no time).

Closing, thanks @vaxerski for your relentless progress! (Funny xcursor scaling issues were also solved after newest release)

[alba4k]

still getting a black screen in most software

[BobVarioa]

Same here as well, also on v0.42.0

[ppenguin]

@alba4k @BobVarioa I'm not sure what to do with this ticket if it's not fixed for you, because I can't reproduce it anymore. I'm not even sure whether the problem is with pipewire, hyprland or xdph. So maybe open a new ticket, preferrably with log output, and refer to this issue as "prior art"? Maybe when gathering logs it could also point more clearly to the culprit? Come to think of it pipewire also got updated recently in nixpkgs, so it might still be part of the equation...

[alba4k]

yeah I was already thinking about doing that :)

[Bill-Klay]

I am able to share a single window if it takes up half of the screen (two tiled windows open), when I share a full screen windows or the entire screen still get the pipewire out of memory buffer error. I've debugged and gone through a lot on my own. Any idea about this?

[MastTheBlast]

Getting the same behavior as @Bill-Klay, where sharing a non-fullscreen application works while sharing a fullscreen application generates the pipewire out of memory buffer error. Not sure if this helps but I've had this issue since v0.40.0, not v0.42.0.

[BobVarioa]

Same here as well, also on v0.42.0

Just wanted to update, all my screen share issues have been fixed as of #249