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)