How to use with Wayland? (Linux)

[kimi-builds]

Works well in X11 windows, but it does nothing in Wayland managed ones. I've read the README and know libx11 is required, but isn't there any way to add compatibility with Wayland? Tested Wayland in Artix Linux kernel v 6.9.2-artix1-1, X in Distrobox's docker.io/library/ubuntu:latest image. What I've tried and logically works is copying text on the server device, activating a X11 managed window launched by Distrobox and then requesting/sending it. But this is a bit too convoluted setup for me unless I actively practice it.

[thevindu-w]

Are you trying to run it in a Docker container (ubuntu:latest)? If so, using xvfb will be easier. That's what I use to run headless tests in a container.

1. Install Xvfb
2. Run Xvfb to create a virtual display. This should run in background.

   Xvfb :0 -screen 0 1280x720x8 >/dev/null 2>&1 &  # you can change resolution and display number

3. Set the DISPLAY environment variable if it's not set. (set it to what you used in step 2)
4. Run ClipShare

This doesn't need creating any window. Xvfb creates one in virtual memory, so this method works even without any display hardware.

Alternatively, you can use Xwayland. There is an issue with getting screenshots on Wayland. But there's a workaround for that as well. I have described this issue and workaround at github.com/thevindu-w/clip_share_server/discussions/20#discussioncomment-7951942

[kimi-builds]

Thanks for the hasty response. Let me stress my workflow, in case it helps you and really anyone to understand my hinder:

• SDDM starts Wayland for me.
• I open an app through Distrobox's distrobox-enter command. It integrates as intended with clip_share, presumably because X is being run in it.
• However, as soon as focus goes back to any window that's not managed by the container's X, requesting data from the mobile app no longer works. When I try running either Xwayland or Xvfb from a post-login Konsole window, the output says that message about a server already running, and then both processes exit.

If you can describe how to run Xwayland under Wayland the way you state in the issue linked above it will be much appreciated.

[thevindu-w]

Isn't it a docker container where you run clip_share inside it?

[kimi-builds]

Isn't it a docker container where you run clip_share inside it?

No, I'm running clip_share from the host. Does that make things more difficult?

[thevindu-w]

No. It should make it easier. Does the host have Wayland? and does it have XWayland? (usually it should have). Also does the host has real display hardware?

[kimi-builds]

No. It should make it easier. Does the host have Wayland? and does it have XWayland? (usually it should have). Also does the host has real display hardware?

Yep, the host has Wayland, XWayland and it is a real display I'm using. As you can see it's kwin_wayland that is launching it:

[thevindu-w]

If you are not using the container having X11 for anything other than clip_share, can you try to stop that container and re-run clip_share on the host without the X container?
Also please check if you have the environment variable DISPLAY set, and there is a socket at /tmp/.X11-unix/X0 (It may be X1 or something other than X0) If you had to set the DISPLAY environment variable, you may need to re-run clip_share.

[kimi-builds]

If you are not using the container having X11 for anything other than clip_share, can you try to stop that container and re-run clip_share on the host without the X container? Also please check if you have the environment variable DISPLAY set, and there is a socket at /tmp/.X11-unix/X0 (It may be X1 or something other than X0) If you had to set the DISPLAY environment variable, you may need to re-run clip_share.

I've installed that Ubuntu container to run the .deb package of MS Edge. DISPLAY is set correctly it seems, :3 like in the XWayland call in the image. But I'll try to run clip_share from within the container actually, I just didn't want to add this extra step in.

[thevindu-w]

What is the DISPLAY variable on the host? Does that variable (on the host) change when you switch between containers? If that changes with the foreground container, things may become complicated.

[kimi-builds]

What is the DISPLAY variable on the host? Does that variable (on the host) change when you switch between containers? If that changes with the foreground container, things may become complicated.

Just tested clip_share from within the container. DISPLAY remains the same (in this case :3). I installed libunistring-dev and the other pkgs you wrote with apt, but this error pops up nevertheless: clip_share: error while loading shared libraries: libunistring.so.5: cannot open shared object file: No such file or directory

[thevindu-w]

You don't need the *-dev packages to run the compiled binaries. Anyway that will install libunistring. But If there's a mismatch in the version of it, this error may occur. Can you mention the original name of the clip_share executable you used? like clip_share-GLIBC_2.38-libssl_3 Probably you should have used the GLIBC 2.38 or 2.39. If you can specify the libunistring version you have, I can help finding the suitable version.

[kimi-builds]

You don't need the *-dev packages to run the compiled binaries. Anyway that will install libunistring. But If there's a mismatch in the version of it, this error may occur. Can you mention the original name of the clip_share executable you used? like clip_share-GLIBC_2.38-libssl_3 Probably you should have used the GLIBC 2.38 or 2.39. If you can specify the libunistring version you have, I can help finding the suitable version.

Did you used the installer script inside the container, where this libunistring issue occured? Seems there's a bug in the installer script where it may use the wrong version. I'll fix that soon (probably by next week). Until then you can try using clip_share_GLIBC-2.35_libssl-3 if that works. What you have to do is replace the current clip_share binary with that file. You can find it by running where clip_share

Okay, I found the clip_share binary that corresponds to the container's GLIBC version. It is 2.35. But running that from within the container achieves the same result: when a X program launched by the container is in focus, managing the clipboard goes as expected; otherwise the mobile client outputs "could not connect"

[thevindu-w]

I guess this focus issue is arising with the containers. If the DISPLAY variable (on the host) change when you switch between containers, it might make issues with clip_share.

[kimi-builds]

I guess this focus issue is arising with the containers. If the DISPLAY variable (on the host) change when you switch between containers, it might make issues with clip_share.

I see your reasoning but entering and leaving the container is not changing the DISPLAY variable in either the container or the host (at least by using the same shell for both)

[thevindu-w]

Then, is there a socket at /tmp/.X11-unix/X0 on the host? (if the DISPLAY variable is something other than :0, the corresponding display number will be the filename instead of X0)

[kimi-builds]

Then, is there a socket at /tmp/.X11-unix/X0 on the host? (if the DISPLAY variable is something other than :0, the corresponding display number will be the filename instead of X0)

Yes, there is, ./X0 and ./X1 as well

[thevindu-w]

Which one is used by the container (if it uses any of them)?

Do these files change (or new files get added) when switching between containers?

Also, try to run clip_share on the host (you need to stop clip_share in the container before doing this), and copy some text on the host (the text should be from an application running directly on the host, not an application running in a container). Does the mobile app get the text in this case? also check if it created a file server_err.log, in the current working directory of the shell, after running clip_share on the host.

[kimi-builds]

Which one is used by the container (if it uses any of them)?

Do these files change (or new files get added) when switching between containers?

Also, try to run clip_share on the host (you need to stop clip_share in the container before doing this), and copy some text on the host (the text should be from an application running directly on the host, not an application running in a container). Does the mobile app get the text in this case? also check if it created a file server_err.log, in the current working directory of the shell, after running clip_share on the host.

I don't know how to find the socket directly, what I know is that both container and host have the DISPLAY variable set to 3. And on your latter suggestion, it's pretty much like I wrote before: I copy any text from an app running on the host, request it in the app and it puts in the mobile clipboard either what was previously selected in clipboard when I had focus on a container app or no output if clipboard was empty at that moment.

[thevindu-w]

DISPLAY variable set to 3

How is this possible when you only have X0 and X1 in /tmp/.X11-unix/? Try setting DISPLAY=:0 or DISPLAY=:1 in the host (using export) and re-run clip_share. Probably one of these should let you get the text copied on an app on the host. To select the correct display number, you can check the DISPLAY variable of any other process running on the host and compare it with what clip_share has.

cat /proc/<pid>/environ | tr '\0' '\n' | grep DISPLAY

Replace the <pid> with a pid of any other process of a GUI app (like a text editor or something) running on the host, and do the same thing with a pid of clip_share process (there can be more than one as it forks). If they are different, use the display number used by the GUI process in clip_share and re-run.

[kimi-builds]

DISPLAY variable set to 3

At that point in time X3 was a socket in that dir in case I wasn't clear. I ran that command from your previous response to get the corresponding DISPLAY of both konsole and clip_share. There were multiple konsole processes but having the same working dir, so I just picked the first one. Grep returned, respectively, for konsole and clip_share: DISPLAY=:1 WAYLAND_DISPLAY=wayland-0

WAYLAND_DISPLAY=wayland-0 DISPLAY=:1

[thevindu-w]

So, if you copy some text in that konsole app, and try to get it from clip_share, does that work? Did you try this while none of the containers are running?

[kimi-builds]

So, if you copy some text in that konsole app, and try to get it from clip_share, does that work? Did you try this while none of the containers are running?

I've just made sure the container was not running. I confirm I can send mobile clipboard to the desktop server, but not request desktop clipboard from the mobile app.

[kimi-builds]

So, if you copy some text in that konsole app, and try to get it from clip_share, does that work? Did you try this while none of the containers are running?

I've just made sure the container was not running. I confirm I can send mobile clipboard to the desktop server, but not request desktop clipboard from the mobile app.

Also tested with podman-desktop on the host, which is an X program. When it's focused ClipShare on mobile can exchange data with the server as usual.

[thevindu-w]

This seems to be an issue with the Wayland. I tried it on Wayland using XWayland to recreate the issue. But it worked as expected and getting copied text worked even when the application was not in the foreground (when a different app has focus). To find out if it's an issue created by clip_share or if it's an external problem (containers, Wayland compositor, etc), can you try xclip and see if it's working? That will help locate the issue.

1. Download xclip (I'm not the author of it). If your pkg management system has binaries, you can use them. Otherwise, compiling from source may be easier. source: github.com/astrand/xclip master branch (you can use it without make install step. The xclip executable is available after running autoreconf, ./configure, and make)
2. Copy some text on an app. (app refers to an app running on the host. Better if you can stop all containers when doing this to isolate the problem)
3. Run the command ./xclip -o -sel clip (if you installed it, then ./xclip should be xclip)
4. If that outputs the text copied in step 2, then run clip_share on the same shell (to have identical environments) and try Get text on mobile client.

If both xclip and clip_share couldn't get text, then try with different DISPLAY environment variables (display numbers can be taken from /tmp/.X11-unix/X* as mentioned in earlier comments). If none of the DISPLAY variable values make it work (xclip or clip_share), things become difficult. If any of them worked (at least for xclip), we can identify what's the issue. If xclip worked and clip_share didn't, I have to check if the changes I made have introduced a bug.

[kimi-builds]

Nope, behavior is the same as clip_share, having tried what you suggested. I mean, the very same. I'll shortly provide a GIF capture of what I mean.

[thevindu-w]

I guess this is restricted by your Wayland compositor. Some compositors like Weston and GNOME Shell with Mutter (on Ubuntu) worked without such issue on getting copied text.

behavior is the same as clip_share.

If xclip has the same issue as clipshare for all display numbers_, then it would be hard to get the copied text. But that also means you can't copy or paste across different GUI apps (that depend on Xwayland) running on host. Is that the situation? Or do you use any clipboard manager app on the host?