[GH-ISSUE #86] Clipboard does not correctly paste large images into xwayland apps #2864

New issue

Closed

opened 2026-05-22 23:52:20 +01:00 by JakeStanger · 2 comments

JakeStanger commented

2026-05-22 23:52:20 +01:00

Owner

Originally created by @JakeStanger on GitHub (Mar 19, 2023).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/86

Describe the bug
When you copy an image that is large enough to buffer from the clipboard, and attempt to paste it into an xwayland app, it will either fail to paste or only paste partial content.

Pasting the same image into a native Wayland app works fine.

To Reproduce
Steps to reproduce the behavior:

Run ironbar with the clipboard module
Copy a large image (>1MB)
Copy anything else
Switch back to the large image using the clipboard module
Attempt to paste into an xwayland app (such as Discord chat, desktop mail client, xwayland browser app)

Expected behavior
The full image should be correctly pasted.

System information:

Distro: Arch Linux
Compositor: Sway (git)
Wlroots git
Ironbar version: 0.10.0 git (d4dd8c4)

λ pacman -Q sway wlroots
sway-force-ssd-git r7095.90c2d631e-1
wlroots-git 0.17.0.r6172.689627f0c-1

Additional context
Have not tested on stable wlroots/compositor, nor on other compositors. Positive this is an xwayland problem, but not sure where in the pipeline the problem lies - presumably there's a workaround for this Ironbar can integrate since the clipboard can normally paste into xwayland apps.

Screenshots
Image dimensions are preserved, but last section is pasted as transparent due to missing data:

Originally created by @JakeStanger on GitHub (Mar 19, 2023). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/86 **Describe the bug** When you copy an image that is large enough to buffer from the clipboard, and attempt to paste it into an xwayland app, it will either fail to paste or only paste partial content. Pasting the same image into a native Wayland app works fine. **To Reproduce** Steps to reproduce the behavior: 1. Run ironbar with the clipboard module 2. Copy a large image (>1MB) 3. Copy anything else 4. Switch back to the large image using the clipboard module 5. Attempt to paste into an xwayland app (such as Discord chat, desktop mail client, xwayland browser app) **Expected behavior** The full image should be correctly pasted. **System information:** - Distro: Arch Linux - Compositor: Sway (git) - Wlroots git - Ironbar version: 0.10.0 git (d4dd8c4) ``` λ pacman -Q sway wlroots sway-force-ssd-git r7095.90c2d631e-1 wlroots-git 0.17.0.r6172.689627f0c-1 ``` **Additional context** Have not tested on stable wlroots/compositor, nor on other compositors. Positive this is an xwayland problem, but not sure where in the pipeline the problem lies - presumably there's a workaround for this Ironbar can integrate since the clipboard can normally paste into xwayland apps. **Screenshots** Image dimensions are preserved, but last section is pasted as transparent due to missing data: ![image](https://user-images.githubusercontent.com/5057870/226190068-8608e41a-effe-4f28-bad6-024f81e3e6f6.png)

JakeStanger

2026-05-22 23:52:20 +01:00

closed this issue
added the
partially resolved

T:Bug

help wanted
labels

JakeStanger commented

2026-05-22 23:52:20 +01:00

Author

Owner

@JakeStanger commented on GitHub (May 5, 2023):

#130 partially resolves this:

The max buffer size has been increased from 16kB to 1MB
There should no longer be any crashes/errors/hangs for larger content, although it still doesn't seem to like pasting.

@JakeStanger commented on GitHub (May 5, 2023): #130 partially resolves this: 1. The max buffer size has been increased from 16kB to 1MB 2. There should no longer be any crashes/errors/hangs for larger content, although it still doesn't seem to like pasting.

JakeStanger commented

2026-05-22 23:52:20 +01:00

Author

Owner

@JakeStanger commented on GitHub (Jul 14, 2023):

Came back to this once again, and I'm still stumped by this. I've had enough of reading kernel man pages and C.

As a temporary workaround, it's possible to just up the kernel max pipe size:

For example, for 10MB:

echo 10485760 > /proc/sys/fs/pipe-max-size

You can probably persist it using sysctl although that seems to be displaying 16MB on my system by default for some reason, when the kernel is using 1MB. Not sure what's going on there either.

@JakeStanger commented on GitHub (Jul 14, 2023): Came back to this once again, and I'm still stumped by this. I've had enough of reading kernel man pages and C. As a temporary workaround, it's possible to just up the kernel max pipe size: For example, for 10MB: ``` echo 10485760 > /proc/sys/fs/pipe-max-size ``` You can probably persist it using `sysctl` although that seems to be displaying 16MB on my system by default for some reason, when the kernel is using 1MB. Not sure what's going on there either.