Closed Bug 1862055 Opened 9 months ago Closed 8 months ago

[Wayland/KDE] Black screen with cursor when screensharing WebRTC on Wayland/Pipewire (again)

Categories

(Core :: WebRTC: Audio/Video, defect, P3)

Firefox 119
x86_64
Linux
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: z411, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(4 files)

Attached image screen_share_ff119.jpg

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:121.0) Gecko/20100101 Firefox/121.0

Steps to reproduce:

I tried to shate the screen through Discord, Google Meet or the test WebRTC Landing Page.

Firefox: 119
xdg-desktop-portal: 1.18
xdg-desktop-portal-kde: 5.27
Pipewire: 0.3.83

Actual results:

It only shows a black screen and only the cursor is visible.

This is a resurface of an old bug. It happens since Firefox 119, doing tests right now with Nightly (121) and the bug is still there. It works in Firefox 118 and below.

Expected results:

The whole screen should be visible.

Component: Untriaged → WebRTC: Audio/Video
OS: Unspecified → Linux
Product: Firefox → Core
Hardware: Unspecified → x86_64
Blocks: pipewire
Priority: -- → P3

Can you use mozregression tool to find broken commit?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
Thanks.

Flags: needinfo?(z411)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #1)

Can you use mozregression tool to find broken commit?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
Thanks.

Thank you for the instructions. I ended up with this pushlog:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7cb12f8540d9d053d281d7ea9cc12c19221c0cfc&tochange=a76cc7cb62be33f979b559dbdf4e259e4bf23b43

I see 4 commits, all related to DMABuf and one specifically related to Pipewire.
I also use this comment to say that I'm using NVIDIA (proprietary drivers), if that's related.

Flags: needinfo?(z411)
Keywords: regression
Regressed by: 1821629

I noted that in these commits the widget.dmabuf.enabled configuration variable was created but changing it has no effect in this particular bug.

I see. Please attach your about:support page.
Thanks.

Flags: needinfo?(z411)
Attached file support.txt

about:support - Brand new profile that exhibits the bug.

Flags: needinfo?(z411)
Severity: -- → S3

I see, it's NVIDIA GeForce GTX 1660 Ti/PCIe/SSE2 drivers, Wayland/KDE.
I see dmabuf is correctly disabled:

DMABUF:
default: available,
env: blocklisted, Blocklisted by gfxInfo, Blocklisted due to known issues: bug 1788573

I wonder why shm screesharing is not used. I'll look at it.

Flags: needinfo?(stransky)

btw. can you try to set 'widget.dmabuf.force-enabled' to true at about:config, restart browser and try again?
Thanks.

Flags: needinfo?(stransky) → needinfo?(z411)
Flags: needinfo?(stransky)
Summary: Black screen with cursor when screensharing WebRTC on Wayland/Pipewire (again) → [Wayland/KDE] Black screen with cursor when screensharing WebRTC on Wayland/Pipewire (again)

I just tested KDE/Wayland with disabled DMABuf and it switched to shm as expected. I wonder why your KDE instance fails to use SHM and just fails in case of disabled dmabuf (but please try to force-enable it by widget.dmabuf.force-enabled).

Flags: needinfo?(stransky)

Thank you, I can confirm it works if I enable widget.dmabuf.force-enabled. I'm assuming this is a driver bug of some sort? Just in case I'm using nvidia-driver 535.113 on Void Linux. Should I take it to the maintainers?

Thank you again.

Flags: needinfo?(z411)

Sorry, mevermind, I remember when I had this issue I switched to Debian Sid temporarily and the issue existed there as well.

(In reply to z411 from comment #10)

Sorry, mevermind, I remember when I had this issue I switched to Debian Sid temporarily and the issue existed there as well.

Looks like we disable dmabug due to your gfx card / driver (there are known bugs on NVIDIA/Dmabuf) but your desktop portal fails to switch to SHM screen share method. Unfortunately webrtc code is missing any logging so we can just guess what's wrong there.

I wonder if you have any KDE option switched to force dmabuf screensharing. Jan, is there any such option?
Thanks.

Flags: needinfo?(jgrulich)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #12)

I wonder if you have any KDE option switched to force dmabuf screensharing. Jan, is there any such option?
Thanks.

There is no such option. This must be failing to negotiate different buffer type for some reason. Since there is an option to force allowing DMA buffers, is there an option to disable them so I can try to reproduce and look what's going on?

Flags: needinfo?(jgrulich) → needinfo?(stransky)

(In reply to Jan Grulich from comment #13)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #12)

I wonder if you have any KDE option switched to force dmabuf screensharing. Jan, is there any such option?
Thanks.

There is no such option. This must be failing to negotiate different buffer type for some reason. Since there is an option to force allowing DMA buffers, is there an option to disable them so I can try to reproduce and look what's going on?

Or nevermind, I can do it in the code :)

Flags: needinfo?(stransky)

As this is the only dmabuf/wayland/NVIDIA bugreport we have I expect it's something broken on the particular setup. Also I tested KDE/Wayland on Fedora 38 and it switched correctly to shm if dmabuf is disabled (but I have AMD gfx card).

I cannot reproduce it. I built latest FF from git, but there were no changes in WebRTC related to screen sharing recently.

What is your version of Plasma? I can see you have 5.27, but I'm interested in the patch release you have. There was a fix I pushed to KWin ~7 months ago so in case you have some older version you might need the fix I did back then.

The particular fix is this one: https://invent.kde.org/plasma/kwin/-/merge_requests/3815

Then it might be a bug or something missing in the NVIDIA driver with my particular GPU - this is far from the first time I've seen weird glitches with Wayland on this driver. As long as I can force enable dmabuf (it works fine for me) and use screen sharing for my work, I'm fine for now. But I can try to provide all the information you might need.

It happened to me in two setups:

Void Linux
nvidia driver: 535.113
KDE Plasma: 5.27.9
KDE Frameworks: 5.111.0
XDG Portal: 1.18.1
XDG KDE Portal: 5.27.9

Debian Linux (Sid)
nvidia driver: 525.125.06
KDE Plasma: 5.27.9
KWin: 5.27.9
KDE Frameworks: 5.107.0
XDG Portal: 1.18.1
XDG KDE Portal: 5.27.9

I'll try to find people who uses nVidia to see if they can reproduce as well.

Can you run pw-mon in a terminal and try to share a screen and attach here the output from that tool?

Flags: needinfo?(z411)
Flags: needinfo?(z411)

Sure. I attached pw-mon output and then tried to screen share, then stopped.
One log has dmabuf force enabled (works), and the other one without dmabuf.force-enable (black screen with cursor only).

I don't see anything wrong in the output from pw-mon, it looks it is actually streaming, but we either fail on import or I don't know. Can you provide the journal log where you grep for kwin_screencast to see if there is anything reported?

Flags: needinfo?(z411)

Can you try whether it works in GNOME?

Can be closed. This is a bug in KDE (KWin compositor).

We identified the issue and the fix is currently submitted for review: https://invent.kde.org/plasma/kwin/-/merge_requests/4651

Status: UNCONFIRMED → RESOLVED
Closed: 8 months ago
Resolution: --- → WONTFIX

This is now also fixed in the new NVidia driver.

Great, thank you guys for your excellent work tracing down the issue.

Flags: needinfo?(z411)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: