Bug 459694 - Cursor on wrong screen in pipewire screen capture
Summary: Cursor on wrong screen in pipewire screen capture
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: screencasting (show other bugs)
Version: git master
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-09-26 11:10 UTC by Eric Armbruster
Modified: 2024-07-10 03:47 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
screencast_double_cursor.png (265.40 KB, image/png)
2022-09-26 11:10 UTC, Eric Armbruster
Details
double_cursor2.png (112.90 KB, image/png)
2022-09-26 12:05 UTC, Eric Armbruster
Details
kwin_support.txt (6.99 KB, text/plain)
2022-09-26 12:10 UTC, Eric Armbruster
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Armbruster 2022-09-26 11:10:03 UTC
Created attachment 152431 [details]
screencast_double_cursor.png

SUMMARY
Cursor on wrong screen in pipewire screen capture

STEPS TO REPRODUCE
1. I have two monitors, Firefox is opened with bigbluebutton on the left monitor.
2. Open a screencast on the right monitor

OBSERVED RESULT
When the cursor is on the left screen it is shown in the screencast although the screencast is of the right screen

In the attachment you can see a screenshot of my left monitor with Firefox and bigbluebutton on it. As you can see my cursor is located on the sidebar of bigbluebutton and at the same time can be seen in the screencapture of my right screen which shows dolphin

EXPECTED RESULT
Cursor is shown on the correct screen in a screen capture

SOFTWARE/OS VERSIONS
git master as of 9/26/22, but I see this at least since 5.25.0

ADDITIONAL INFORMATION
Comment 1 Vlad Zahorodnii 2022-09-26 11:56:59 UTC
I cannot reproduce it. I used https://mozilla.github.io/webrtc-landing/gum_test.html (Screen capture) for testing.
Comment 2 Vlad Zahorodnii 2022-09-26 11:57:50 UTC
Are you on wayland or X11 though?
Comment 3 Eric Armbruster 2022-09-26 12:05:30 UTC
Created attachment 152432 [details]
double_cursor2.png

On wayland. I have this bug also with the tool you used. Obviously the real problem is that when I use screencasting the other people cannot see my mouse, as it is always on the wrong screen.
Comment 4 Eric Armbruster 2022-09-26 12:10:23 UTC
Created attachment 152433 [details]
kwin_support.txt
Comment 5 Eric Armbruster 2022-09-26 12:25:05 UTC
Interestingly, it does seem to matter which screen I capture and on which screen firefox is. When I take a screencapture of my right screen with firefox on my right screen I cannot see the mouse at all in the capture (even when I move it to my left screen). When I then move firefox from my right screen to my left screen, I can again see the bug I originally described. Also, when I move my mouse now from the left to the right screen "the wrong mouse in the capture" gets stuck once my mouse crosses the screen border and stays visible in the capture.
Comment 6 Aleix Pol 2022-09-26 16:17:51 UTC
I too have been unable to reproduce the problem.

I'm surprised because my firefox (105.0.1) doesn't even request a cursor, so I don't really understand why yours does. Are you maybe running a development build? What distro are you on?

If I force Plasma (XDPK) to send the cursor, it also does render it in the correct place. :(
Comment 7 Aleix Pol 2022-09-26 16:22:53 UTC
Is your firefox running on X11 or Wayland?
Comment 8 Aleix Pol 2022-09-26 16:32:50 UTC
I see the cursor appears sometimes when on "no-cursor" mode when hovering an Xwayland client.

:|
Comment 9 Aleix Pol 2022-09-26 17:16:55 UTC
My best guess so far is that Firefox is trying to get the cursor from X11 events and does a rather poor best guess.

Please see if OBS or chromium* work for you.

*chromium --enable-features=UseOzonePlatform,WebRTCPipeWireCapturer --ozone-platform=wayland
Comment 10 Eric Armbruster 2022-09-27 07:28:48 UTC
Firfox is running in X11 mode.
Tested with obs, chromium, and chromium --enable-features=UseOzonePlatform,WebRTCPipeWireCapturer --ozone-platform=wayland and it  works nicely. 

I had Aleix patch https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/128 (I know it's probably unrelated, just so you know) during all these tests enabled and verified that firefox is still showing the old behavior.
Comment 11 Jan Grulich 2022-09-27 08:33:23 UTC
Firefox has outdated WebRTC with outdated screen sharing support. Luckily, the next Firefox release (106) will have rebased WebRTC and should be finally on par with Chromium and fix your issue.

It's hard to say if the issue is now happening because of a bug in Firefox or because there is a bug when an embedded cursor is used (Firefox defaults to embedded cursor instead of metadata). This will be hard to verify as both OBS and Chromium defaults to use cursor metadata for better effeciency.

Aleix, you can possibly try to patch OBS and try use embedded cursor instead of metadata. It should be just a matter of changing one value OBS sends to portals.
Comment 12 Eric Armbruster 2022-11-09 14:32:26 UTC
I can still reproduce this with Firefox 1.06

Operating System: Arch Linux
KDE Plasma Version: 5.26.3
KDE Frameworks Version: 5.99.0
Qt Version: 5.15.7
Kernel Version: 6.0.7-zen1-1-zen (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 3700X 8-Core Processor
Memory: 15.5 GiB of RAM
Graphics Processor: AMD Radeon RX 5700 XT
Comment 13 Eric Armbruster 2022-11-09 14:37:06 UTC
I tested now also with firefox developer edition to make sure none of my settings/addons are responsible for this.
Comment 14 Jan Grulich 2022-11-14 11:31:33 UTC
Firefox is still using old WebRTC code for screen sharing, even though they have the new one available. 

FF is blocked on https://bugzilla.mozilla.org/show_bug.cgi?id=1777345.
Comment 15 Vlad Zahorodnii 2024-06-10 11:55:07 UTC
Is the issue still reproducible in 6.0.5 or 6.1 beta?
Comment 16 Bug Janitor Service 2024-06-25 03:47:27 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 17 Bug Janitor Service 2024-07-10 03:47:16 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!