ClipCascade try to use wayland on xserver

[Unknow0]

Hi,

i run clipcascade (3.0.0) from .config/openbox/autostart.sh (i added --xmode then --gui to try to force the x11 usage instead of wayland)

[ "$DISPLAY" = ":0" ] && (sleep 1
        python3 /opt/ClipCascade/main.py --xmode true --gui true > ~/.clipcascade.log 2>&1 &
)

but in the log i seem clipcascade try to use wayland:

(main.py:1956): libayatana-appindicator-WARNING **: 09:32:50.781: libayatana-appindicator is deprecated. Please use libayatana-appindicator-glib in newly written code.

(main.py:1956): Gdk-CRITICAL **: 09:32:50.930: gdk_window_thaw_toplevel_updates: assertion 'window->update_and_descendants_freeze_count > 0' failed
Failed to connect to a Wayland server: No such file or directory
Note: WAYLAND_DISPLAY is unset (falling back to wayland-0)
Note: XDG_RUNTIME_DIR is set to /run/user/1001
Please check whether /run/user/1001/wayland-0 socket exists and is accessible.
Failed to connect to a Wayland server: No such file or directory
Note: WAYLAND_DISPLAY is unset (falling back to wayland-0)
Note: XDG_RUNTIME_DIR is set to /run/user/1001
Please check whether /run/user/1001/wayland-0 socket exists and is accessible.

if i launch it manually sometime it works as expected, but sometime i have the same issue as the autostart.sh

do you know why it try wayland instead of x11 even with --xmode true ?

the env variable i have:

$ echo $XDG_SESSION_TYPE
x11
$ echo $WAYLAND_DISPLAY

$ echo $DISPLAY
:0

Regards.

[Sathvik-Rao]

Hi @Unknow0 ,

Are you using the latest desktop app version 3.2.0?

You're currently mentioning 3.0.0, and there have been updates since then.

Also, since you are launching it from an Openbox startup script, it is possible the X11 display server or session environment is not fully initialized yet during login/startup. That can sometimes cause different behavior between autostart execution and manually launching the app after the desktop session has fully loaded.

[Unknow0]

Hi @Sathvik-Rao,

I found that xclip -selection clipboard -t TARGETS -o return an error instead of the list of available targets without the -selection clipboard it does return the list as expected

so removing the "-selection, "clipboard", in ClipCascade_Desktop/src/clipboard/clipboard_monitor_linux.py line 79 and 375 does seem to fix my issue

i will try to update to 3.2.0 first if it doesn't fix it i can do a pull request

Regards.

[Unknow0]

Hi @Sathvik-Rao,

i have updated the client to 3.2 and i have the same issue with the xclip command

running clipcascade from openbox/autostart.sh it works half way (copy from it to other pc works, but from other to it doesn't) even with --xmode true --gui true

2026-06-04 12:08:41,544 - INFO - XMODE: True
2026-06-04 12:08:41,545 - INFO - Starting GTK clipboard monitoring for X11 display server.
2026-06-04 12:08:41,648 - INFO - Websocket connected
[...]
2026-06-04 12:09:07,259 - ERROR - Failed to execute command: Command '('wl-copy',)' returned non-zero exit status 1.
2026-06-04 12:09:07,259 - ERROR - Failed to copy data to clipboard: Command '('wl-copy',)' returned non-zero exit status 1.
2026-06-04 12:09:07,259 - ERROR - Failed to convert base64 data to clipboard: Command '('wl-copy',)' returned non-zero exit status 1.

but running from a terminal works, at a glace the env variable seem similar, not WAYLAND, DISPLAY=:0 and all XDG_* env are the same

Do you know what can be the cause ?

Regards.

[trouni]

I hit this too, on X11 with ClipCascade started from a systemd user unit. I think the root cause sits one layer deeper than the xclip command itself — in clipboard_manager.py rather than clipboard_monitor_linux.py.

ClipboardManager.paste() picks its tool with XMODE and self.is_x_clipboard_owner (clipboard_manager.py:221 and :261), which ANDs two unrelated signals:

• XMODE already answers the question — it comes from XDG_SESSION_TYPE via detect_linux_display_server(), so it is True on X11 and XWayland.
• is_x_clipboard_owner() answers "does something currently hold the CLIPBOARD selection". That says nothing about which tool can write to it, and xclip -selection clipboard does not need a prior owner — it becomes one.

The probe also runs only once, in __init__ (:41), and is cached for the process lifetime. That is what makes this autostart-specific: when ClipCascade starts before anything has been copied, the probe fails, the cached value is False, and every later paste takes the wl-copy branch for the whole session. Launch it manually after copying something and the probe succeeds, which is why it looks intermittent.

This is also the same bug as #99 from March 2025 — that reporter independently narrowed it to "happens at login, not when run manually", which is the same race. It was closed because they stopped using the app, not because it was fixed.

Selecting the tool by display server alone fixes it:

-                    if XMODE and self.is_x_clipboard_owner:
+                    if XMODE:

in both the text and image paths, plus dropping the now-unused probe from __init__. I have opened #171 with that change.

It is complementary to @Unknow0's #157 rather than competing — that one changes the probe command in the monitor, this one changes the paste decision in the manager, and they touch different files.

@Unknow0 one thing worth checking on #157: xclip defaults to the PRIMARY selection, so dropping -selection clipboard makes the line-79 hunk poll PRIMARY rather than CLIPBOARD in the monitor's read loop — I think that would end up syncing the mouse-selection buffer. The is_x_clipboard_owner() hunk also makes the probe more likely to succeed rather than removing the dependency on it, so a fresh login with nothing selected could still land on the wl-copy branch.

Verified on X11 by forcing is_x_clipboard_owner() to return False (the bug condition), calling paste(), and confirming it selects xclip and the text lands. I do not have an XWayland box, so the case where XMODE is also True there could use a second pair of eyes.

[Unknow0]

Hi,

i confirm the behavior & fix of @trouni

if i run clipcascade manualy it also try to use wayland tool, but if i copy something before running clipcascade it use xclip properly

also you're right my change aren't good.

I think you should totally remove the is_x_clipboard_owner, as it's only use in _start_clipboard_polling and if it return false we will revert to use wayland tools to get the clipboard type and content which would fail

Regards.