Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shared Clipboard not Functioning with Wayland #3455

Closed
mariaWitch opened this issue Mar 1, 2023 · 19 comments · Fixed by #6586
Closed

Shared Clipboard not Functioning with Wayland #3455

mariaWitch opened this issue Mar 1, 2023 · 19 comments · Fixed by #6586

Comments

@mariaWitch
Copy link

mariaWitch commented Mar 1, 2023

Bug Description

The shared clipboard does not seem to function between my host and my client, when the client is running on Wayland DE. (Note this is occurring on the latest passing nightly build (Build #203 in the project actions) so it may also be a more wide spread problem.)

How to Reproduce

Connect to a client that is running a Wayland Compatible version of Rustdesk.
Attempt to copy text from host to client, or vice versa.

Expected Behavior

The clipboard should be shared between both clients.

Operating system(s) on local side and remote side

Windows 11 -> Ubuntu 22.04 (Linux 6.2.1)

RustDesk Version(s) on local side and remote side

1.1.9 -> 1.2.0 (The most recent passing Nightly artifact)

Screenshots

N/A

Additional Context

No response

@rustdesk
Copy link
Owner

rustdesk commented Mar 2, 2023

@fufesou

@Dicer-J
Copy link

Dicer-J commented Apr 10, 2023

How do I get the Wayland DE, please?

@madsl
Copy link

madsl commented Apr 27, 2023

Copy/Paste works if you copy/paste from an XWayland program. Would be neat if it would work from native Wayland apps too.

@madsl
Copy link

madsl commented Apr 27, 2023

Tip: If you start e.g. kwrite like this
QT_QPA_PLATFORM=xcb kwrite
then you can use that window to copy/paste to and from.

@muety
Copy link
Sponsor

muety commented Jun 4, 2023

Would love to have this fixed! :-)

@ShellWen
Copy link

The current workaround for this issue is to use GDK_BACKEND=x11 rustdesk to force RustDesk to run within XWayland, which helps alleviate the problem.

@bayazidbh
Copy link

@rustdesk
Copy link
Owner

/bounty $100

@algora-pbc
Copy link

algora-pbc bot commented Sep 21, 2023

💎 $100 bounty created by rustdesk
🙋 If you start working on this, comment /attempt #3455 to notify everyone
👉 To claim this bounty, submit a pull request that includes the text /claim #3455 somewhere in its body
📝 Before proceeding, please make sure you can receive payouts in your country
💵 Payment arrives in your account 2-5 days after the bounty is rewarded
💯 You keep 100% of the bounty award
🙏 Thank you for contributing to rustdesk/rustdesk!

Attempt Started (GMT+0) Solution
🟢 @ShellWen Oct 2, 2023, 2:17:03 AM WIP

@ShellWen
Copy link

ShellWen commented Oct 2, 2023

/attempt #3455

Options

ShellWen added a commit to ShellWen/rustdesk that referenced this issue Oct 3, 2023
Add feature `wayland-data-control` to dependency `arboard`.

Fix rustdesk#3455
@beelchester
Copy link
Contributor

beelchester commented Nov 10, 2023

#5900 seems to be lacking compatibility.

I think using the remote desktop portal (org.freedesktop.portal.RemoteDesktop) can be a good option.
https://flatpak.github.io/xdg-desktop-portal/docs/#gdbus-org.freedesktop.portal.RemoteDesktop
It has support for clipboard.

Currently, we are only using org.freedesktop.portal.ScreenCast for the pipewire session.

"org.freedesktop.portal.ScreenCast",

On the other hand, using org.freedesktop.portal.RemoteDesktop will also fix input on flatpak wayland #5949 (This issue also has a bounty) as it supports the transfer of input events to an EIS, you might have to do separate implementation for libei to further emulate inputs.
uinput might not be needed anymore.

You can check this too for understanding.
#56 (comment)
#4906: Teamviewer also seems to be using it.
#3455 (comment)

@ShellWen and others interested can have a look at it. You might fix two issues at once.


@fufesou please verify if using org.freedesktop.portal.RemoteDesktop can be feasible or not.

@ShellWen
Copy link

I don't know how KDE Connect do this. Anyone take a look?

@beelchester
Copy link
Contributor

@ShellWen
Copy link

You can check their code https://github.com/KDE/kdeconnect-kde/tree/master/plugins/clipboard

I means control of mouse and keyboard.

@ShellWen
Copy link

@beelchester
Copy link
Contributor

beelchester commented Nov 11, 2023

@ShellWen
Copy link

I suspect they are using org.freedesktop.portal.RemoteDesktop #3455 (comment) https://github.com/KDE/kdeconnect-kde/blob/14192dd9c463ffa40d0cb66a2631395432d37517/plugins/mousepad/waylandremoteinput.cpp#L62

Another problem: is this work under systemd unit?

@beelchester
Copy link
Contributor

beelchester commented Nov 11, 2023

I'm not sure but using org.freedesktop.portal.RemoteDesktop will not require root access (couldn't find the need for root in the doc), even for emulating input events libei might not require root permission unlike uinput.

We are already using org.freedesktop.portal.ScreenCast. org.freedesktop.portal.RemoteDesktop just provides more features on top of it, so it shouldn't be a problem.

@cantalupo555
Copy link

cantalupo555 commented Jun 10, 2024

The current workaround for this issue is to use GDK_BACKEND=x11 rustdesk to force RustDesk to run within XWayland, which helps alleviate the problem.

Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants