clipboard sharing with Wine apps does not work in Hyprland. It's fine with Swaywm and other wayland WMs

[simonm]

As the title suggests, I cannot get clipboard sharing to work between wine applications and hyprland.

I've simplified the issue and can replicate easily using just notepad.exe.

Copying from notepad.exe running under Wine successfully goes to the Wayland WM clipboard.

Copying from Wayland / Hyprland does NOT go to the clipboard in Wine.

Clipboard is fine in both directions with swaywm (which is where I am migrating from). I am using the same setup - with copyq - managing the clipboard in both places.

I have also been able to replicate the same results using the recommended / documented clipboard settings in the Hyprland Wiki:

exec-once = copyq --start-server

and separately,

exec-once = wl-paste --type text --watch cliphist store #Stores only text data exec-once = wl-paste --type image --watch cliphist store #Stores only image data

The problem seems to only occur in Hyprland, which is why I raise this.

Is there a suggestion to help me troubleshoot root cause please?

Thank you!

Hyprland, built from branch  at commit f27873a6f06dc2f87600edb890f3c38298bfb55f dirty ().
Tag: v0.25.0

flags: (if any)~```

[GutsyHeart]

Clipboard sharing works in wine-wayland

[eiseq]

click

[simonm]

Clipboard sharing works in wine-wayland

EDIT: Now wait a second. I think we've got it. It's working now. Thank you very much.

It does not for me. Just tested.

I am very specifically talking about clipboard copy from Wine to Wayland / X-Wayland with Hyprland. From Wayland / X-Wayland to Wine is fine.

I just tried wine-wayland (Arch, wine-wl-git, 8.2.r928.gb2547ddf9e0-1) - exactly the same issue. Is there anything I can do to help troubleshoot this?

[xadips]

https://aur.archlinux.org/packages/wine-wl-git solves the issue for me as well.

@simonm if Issue is solved you could close the issue ;)

[simonm]

Yes - this solved it. Many thanks all!

[Hellzbellz123]

having wine-wl-git installed does not fix the issue for me, cant copy paste into any apps running wine and its driving me crazy

[xadips]

Are the games usin the correct wine version in lutris or pure wine, I am also using a clipboard history retaining service clipmon https://git.sr.ht/~whynothugo/clipmon maybe using a clipboard retaining service is also a requirement.

[Hellzbellz123]

Are the games usin the correct wine version in lutris or pure wine, I am also using a clipboard history retaining service clipmon git.sr.ht/~whynothugo/clipmon maybe using a clipboard retaining service is also a requirement.

ive tried a couple of different configurations, at first it was just wl-clip-persist and it didnt work, so i tried getting a clipboard manager and syncing the primary and secondary and it didnt work. then i tried installing wl-clipboard-x11 which is a wrapper around xclip/xsel because i didnt have them, still didnt work. then i tried syncing the clipboards with wl-paste -pw wl-copy and copyq but it still doesnt work im trying too copy paste into the notepad that ships with wine, so its wine-wl's notepad app. i cant copy paste into it, but i can copy from it, it will let me copy paste from wine too proton but not wayland too proton or wayland too wine

[rkanati]

@simonm can you please re-open this? the bug isn't fixed, and "use a different wine" isn't applicable for everyone

[CobaltSpace]

An actual fix may be wl-paste -t text -w xclip -selection clipboard. This has fixed it for me in a proton game, and in Unity editor. This uses the actual xclip, not wl-clipboard-x11.

exec-once = wl-paste -t text -w xclip -selection clipboard

[rkanati]

An actual fix may be wl-paste -t text -w xclip -selection clipboard.

Nice. Still a workaround though, not a fix.

@vaxerski could you re-open this?

[Hubro]

This has annoyed me for months, just found this ticket today. Using a different wine is not an alternative, I already use specific Wine versions with specific patches to address other issues through Bottles. Glad to see there' a workaround though, so I don't have to manually type out my 35 character random password into the Baldur's Gate 3 launcher.

[CobaltSpace]

wl-paste -t text -w xclip -selection clipboard does have some issues. It will start copying constantly if the copy source uses the X clipboard. So it is indeed just a workaround for now.

[Menelkir]

And funny that it doesn't work all the time, I'm not sure where the problem is. I had some issues between termite and firefox which doesn't exists anymore with this workaround, but between XWayland or Wine applications it's a hit-and-miss.

[CobaltSpace]

wl-paste -t text -w sh -c 'xclip -selection clipboard -o > /dev/null 2> /dev/null || xclip -selection clipboard' fixes the infinite copying issue that occurs in X applications.

Also, without the xclip workaround, I noticed that xclip -selection clipboard -o gives Error: target STRING not available on stderr when the copy is from a wayland application. It appears that the X clipboard gets cleared when copying from a wayland application, but does not receive the new thing that is copied.

I think the reason the infinite copying occurs is that when xclip copies while an X application is focused, it gets forwarded to the wayland clipboard, which causes wl-paste -w to trigger, causing xclip to copy again, creating the loop. The new workaround prevents this by only copying with xclip if xclip errors out trying to paste.

Edit: the command is inconsistent. I now use wl-paste -t text -w sh -c '[ "$(xclip -selection clipboard -o)" = "$(wl-paste -n)" ] || xclip -selection clipboard'

[simonm]

Re-opening as per the request in the comments.

Don't overlook the possible issue of PRIMARY v CLIPOBOARD on Xorg or Wayland. You'll need to set up clipboard synchronisation as others have commented. I use copyq. There are other options.

[Menelkir]

I've tried using copyq and I've made several tests on this regard, when it doesn't copy something on this regard, copyq is totally ignored.

[simonm]

Hi @Menelkir - It may be copying to the "wrong" clipboard.

What happens if you look at copyq toggle UI? Is your copied text there?

'But - let me add: It only started working when I installed wine-wl-git

[Menelkir]

It doesn't show any text unless I use the workaround. I even have a shortcut for copyq toggle to check I've tried wine-wl-git and didn't changed the scenario for me.

[moetayuko]

wl-paste -t text -w sh -c 'xclip -selection clipboard -o > /dev/null 2> /dev/null || xclip -selection clipboard' fixes the infinite copying issue that occurs in X applications.

This seems to work fine Edit: still problematic. I'm now using wl-paste -t text -w sh -c 'v=$(cat); cmp -s <(xclip -selection clipboard -o) <<< "$v" || xclip -selection clipboard <<< "$v"'

Edit: the command is inconsistent. I now use wl-paste -t text -w sh -c '[ "$(xclip -selection clipboard -o)" = "$(wl-paste -n)" ] || xclip -selection clipboard'

This will freeze the program when copying large texts. e.g. copying https://github.com/torvalds/linux/blob/master/Makefile from firefox (native wayland mode), then firefox will freeze.

[Hubro]

Just out of curiosity, is it clear what the issue is here? From the workarounds, it sounds to me like Hyprland should put copied text into the "XA_CLIPBOARD" selection in the Xwayland clipboard, rather than "XA_PRIMARY" (or maybe both?). If so, isn't this a trivial one-line fix? :thinking:

[rkanati]

If so, isn't this a trivial one-line fix? 🤔

given that sway doesn't have this problem, i assume it's a small problem with a simple fix buried somewhere in the code. unfortunately i'm not familiar enough with either project to know how to approach it without help.

[moetayuko]

I failed to launch wine in nested hyprland session, but wps, another xwayland app that can't paste things from native wayland.

Here's wlroots log when trying to copy sth when another random xwayland app opened:

[wlr] [xwayland/selection/incoming.c:485] XCB_XFIXES_SELECTION_NOTIFY (selection=270, owner=2097153)

Here's the one when wps opened:

[wlr] [xwayland/selection/incoming.c:485] XCB_XFIXES_SELECTION_NOTIFY (selection=270, owner=2097153) [wlr] [xwayland/selection/outgoing.c:375] XCB_SELECTION_REQUEST (time=20628677 owner=2097153, requestor=4194394 selection=270, target=272, property=322) [wlr] [xwayland/selection/outgoing.c:417] denying read access to selection 270 (CLIPBOARD): no xwayland surface focused [wlr] [xwayland/selection/outgoing.c:26] SendEvent destination=4194394 SelectionNotify(31) time=20628677 requestor=4194394 selection=270 target=272 property=0 [wlr] [xwayland/selection/outgoing.c:375] XCB_SELECTION_REQUEST (time=20628677 owner=2097153, requestor=4194394 selection=270, target=272, property=322) [wlr] [xwayland/selection/outgoing.c:417] denying read access to selection 270 (CLIPBOARD): no xwayland surface focused [wlr] [xwayland/selection/outgoing.c:26] SendEvent destination=4194394 SelectionNotify(31) time=20628677 requestor=4194394 selection=270 target=272 property=0

The log above indicates that wps is trying to read from clipboard right after we yanked something, and the read is denied by wlroots because xwayland window is not focused. But if I keep mouse focusing on wps window when copying with wl-copy, it succeed to paste after that:

[wlr] [xwayland/selection/incoming.c:485] XCB_XFIXES_SELECTION_NOTIFY (selection=270, owner=2097153) [wlr] [xwayland/selection/outgoing.c:375] XCB_SELECTION_REQUEST (time=20939177 owner=2097153, requestor=4194394 selection=270, target=272, property=322) [wlr] [xwayland/selection/outgoing.c:26] SendEvent destination=4194394 SelectionNotify(31) time=20939177 requestor=4194394 selection=270 target=272 property=322 [wlr] [xwayland/xwm.c:902] unhandled X11 property 322 (_QT_SELECTION) for window 4194394 [wlr] [xwayland/xwm.c:902] unhandled X11 property 322 (_QT_SELECTION) for window 4194394

I guess the cause for wine is the same, and an obvious workaround looks to me is to bypass the denial of wlroots. I don't know how sway deal with such issue.

[rkanati]

nicely done! but if this is indeed the problem, what is sway doing differently that avoids it?

[moetayuko]

I sent a PR to wlroots https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4359, which drops the restriction of unfocused xwayland apps to read clipboard. Pasting contents from native wayland to wine works with it.

[myned]

restriction of unfocused xwayland apps to read clipboard.

This hint helped me fix the issue I was having with Warframe, which now pastes properly using the forceinput window rule:

forceinput, class:^steam_app_.*$

Not sure if this has side effects yet, but it works fine for my usecase. Hopefully that PR is merged so this doesn't have to be worked around by the user.

Edit: In the case of Warframe, this does not work as expected. I assumed it did due to restarting the game allowing pasting even without forceinput. I've taken to using the xclip workaround instead.

[dragonnn]

wl-paste -t text -w sh -c 'v=$(cat); cmp -s <(xclip -selection clipboard -o) <<< "$v" || xclip -selection clipboard <<< "$v"'

This breaks coping images from/into xwayland apps at least on my system. When I copy an image from my web browser into another window I get the html of the image instead of the image itself. That works fine when wl-paste is not running or I use wl-paste only to puch stuff into cliphist. What would be best way to add cliphist store to that workaround? Thanks!

[moetayuko]

wl-paste -t text -w sh -c 'v=$(cat); cmp -s <(xclip -selection clipboard -o) <<< "$v" || xclip -selection clipboard <<< "$v"'

This breaks coping images from/into xwayland apps at least on my system. When I copy an image from my web browser into another window I get the html of the image instead of the image itself. That works fine when wl-paste is not running or I use wl-paste only to puch stuff into cliphist. What would be best way to add cliphist store to that workaround? Thanks!

I have an aur package w/o the xwayland clipboard restriction of wlroots. Unfortunately, it won't get upstreamed because wlroots maintainers don't think dropping the restriction is the right thing to do

[dragonnn]

Thanks! Far from perfect solution especially that it completely messed up hyprpm and I need to build split-monitor-workspaces by hand but got it working so I am fine for now. Hope a upstream solution will be found some day.

[Plyply99]

Hope a upstream solution will be found some day.

Agreed. This is my only real issue with Hyprland. I'm currently using the the wl-paste with cliphist method but it's insanely buggy and most of the time I have to swap workspaces to even get it to function at all.

[99linesofcode]

@vaxerski I'm curious to hear if there are any solutions you can think of that don't involve installing custom versions of wine or hyprland :smile:

[99linesofcode]

An actual fix may be wl-paste -t text -w xclip -selection clipboard. This has fixed it for me in a proton game, and in Unity editor. This uses the actual xclip, not wl-clipboard-x11.

exec-once = wl-paste -t text -w xclip -selection clipboard

Opted for this workaround as well. Stable Wayland support for Wine and Proton should be around the corner but as I understand it this is more of a wayland / xwayland issue, correct?

exec-once = wl-paste -w cliphist store -w xclip -selection clipboard

That doesn't work for me either. Whatever is in my clipboard prior to starting up a game in Proton is accessible (with or without the xclip workaround) but any consecutive copy paste is not picked up on. Need to learn more about this before I can contribute anything sensible to the discussion.

[zetaPRIME]

wl-paste -t text -w bash -c '[ "$(xclip -selection clipboard -o)" = "$(wl-paste -n)" ] || [ "$(wl-paste -l | grep image)" = "" ] && xclip -selection clipboard'

A version of the workaround that declines transfer if the copy contains image formats.

[moetayuko]

tools including wl-clipboard and xclip are unable to perfectly keep wayland and x clipboards in sync because they can't forward every mime types of the yanked stuff, check wl-paste -l and xclip -selection clipboard -o -t TARGETS

[minh2134]

wl-paste -t text -w bash -c '[ "$(xclip -selection clipboard -o)" = "$(wl-paste -n)" ] || [ "$(wl-paste -l | grep image)" = "" ] && xclip -selection clipboard'

A version of the workaround that declines transfer if the copy contains image formats.

This used to work for me but recently it broke.

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  18 (X_ChangeProperty)
  Resource id in failed request:  0x20aa39
  Serial number of failed request:  22
  Current serial number in output stream:  25
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  18 (X_ChangeProperty)
  Resource id in failed request:  0x20aa3c
  Serial number of failed request:  22
  Current serial number in output stream:  25
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  18 (X_ChangeProperty)
  Resource id in failed request:  0x20aa3f
  Serial number of failed request:  22
  Current serial number in output stream:  25
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  18 (X_ChangeProperty)
  Resource id in failed request:  0x20aa42
  Serial number of failed request:  22
  Current serial number in output stream:  25

this log is repeated ad infinitum with random resource id.