I’ve spent a ton of time troubleshooting this and it seems like crystaldock won’t work when the dock is in the bottom OR right side of my monitor. I also had a whole bunch of odd issues with my secondary monitor (which is on the right in vertical orientation).
For now, I’ve consolidated to only using crystal dock on my left monitor (in landscape orientation) and with auto-hide on.
Lengthy analysis as follows…
Summary:
After upgrading 24.04 → 26.04 LTS, Crystal Dock exhibits two distinct
but related bugs in its layer-shell positioning logic:
Bug A — Clicks fail when the dock is anchored to the bottom or right
edge of any screen. Top and left edges work normally.
Bug B — The dock fails to render at all on a monitor that is not at
desktop position (0,0). Render success follows the monitor’s
position in the compositor’s coordinate space, not the monitor’s
identity, cable type, or rotation.
Both bugs follow the same pattern: rendering and input behave correctly
when anchored to coordinate origin, and break when anchored to non-zero
coordinates. Likely shared root cause.
==============================================================
Bug A: Clicks fail on bottom/right anchored docks
Expected:
Clicks on Crystal Dock launchers and task icons activate or launch the
corresponding application regardless of which screen edge the dock is
anchored to.
Actual:
Clicks have no effect when the dock is at the bottom or right edge.
The dock displays correctly, animates, and updates task icon state at
all positions — only input delivery is broken. Running crystal-dock
from a terminal produces no output when clicking on a non-functional
dock; input events do not appear to reach the process.
Reproduction (per-position):
killall crystal-dock
sed -i ‘s/position=[0-3]/position=N/’
~/.config/crystal-dock/Budgie/panel_1.conf
crystal-dock &
Where N is 0=Top, 1=Bottom, 2=Left, 3=Right.
Test matrix (4 positions, single panel on monitor at desktop origin):
Top Bottom Left Right
Monitor 0 OK FAIL OK FAIL
Pattern: clicks work on edges anchored at coordinate origin (top, left).
Clicks fail on edges anchored at the far end of the screen (bottom,
right).
Note: Bug B prevented direct testing of click behavior on the second
monitor in its native position. When the second monitor was temporarily
relocated to desktop position (0,0) for testing, rendering succeeded
and the click-failure pattern matched monitor 0 exactly.
==============================================================
Bug B: Render fails on non-origin monitors
Expected:
A panel with screen=N renders on output N regardless of where output N
is positioned in the desktop coordinate space.
Actual:
The panel renders only when the target output is at desktop position
(0,0). On any other output position, the panel does not appear
anywhere on screen, despite valid configuration.
Reproduction:
- Two monitors. Verify positions with wlr-randr.
Initial state: HDMI-A-1 at (0,297), DP-2 at (1920,0).
- Configure two crystal-dock panels: panel_1 with screen=0,
panel_2 with screen=1. Both with valid identical settings
(position=2, visibility=2).
- Launch crystal-dock. Result: panel_1 renders on HDMI-A-1.
panel_2 does not appear anywhere.
- Swap screen= assignments between the two config files
(panel_1 → screen=1, panel_2 → screen=0). Relaunch.
Result: still only one dock renders, on HDMI-A-1 (now targeted by
panel_2). The dock targeting DP-2 still does not appear. Bug
follows the monitor, not the config file.
- Reposition monitors so DP-2 is at (0,0) and HDMI-A-1 is at
(1920,0):
wlr-randr --output DP-2 --pos 0,0 --transform normal
wlr-randr --output HDMI-A-1 --pos 1920,0
Relaunch crystal-dock.
Result: dock now renders on DP-2 (now at origin). The other dock,
targeting HDMI-A-1 (now at 1920,0), does not appear.
Conclusion: rendering capability is gated on the target monitor being
at desktop position (0,0), regardless of which physical output it is.
Cable type, rotation, and identity are not factors.
==============================================================
Hypothesis (single root cause for both bugs)
Crystal Dock prints a deprecation warning at every startup:
LayerShellQt.Window.screenConfiguration is deprecated use screen
and wantsToBeOnActiveScreen instead
The deprecated API specifically concerns layer-shell screen
positioning. Both bugs match the pattern of code that hard-codes
coordinate origin (0,0) somewhere it should be computing relative to
the target output’s position and dimensions:
- Bug A: input region origin appears to be hard-coded at (0,0),
so clicks only register on docks visually located at low
coordinates (top, left edges).
- Bug B: render-target origin appears to be hard-coded at desktop
(0,0), so docks targeting offset monitors are positioned outside
those monitors’ visible area.
Migrating Crystal Dock to LayerShellQt’s modern screen +
wantsToBeOnActiveScreen API may resolve both bugs simultaneously.
==============================================================
Environment
Ubuntu Budgie 26.04 LTS (resolute), upgraded from 24.04
Compositor/session: labwc / Budgie / Wayland
XDG_SESSION_TYPE=wayland
XDG_CURRENT_DESKTOP=Budgie
Crystal Dock 2.16-1 from resolute/universe
No PPAs or third-party sources contributing crystal-dock or
LayerShellQt
GPU: Intel HD Graphics 630 (i5-7500T, Kaby Lake)
Hardware: bare metal mini-PC, not a VM
Monitors:
HDMI-A-1: Dell U2415, 1920x1200, position (0,297), transform normal
DP-2: Dell U2410, 1920x1200, position (1920,0), transform 90
16 GB RAM, no resource pressure
==============================================================
Workarounds tried (none affected either bug)
- killall crystal-dock followed by relaunch
- X-GNOME-Autostart-Delay raised from 5s (default) to 15s
- Full config reset to distro defaults from /etc/xdg/crystal-dock/
- XDG_CURRENT_DESKTOP=Labwc to bypass the Budgie code path
(welcome dialog accepted clicks normally; resulting bottom-anchored
dock still received no clicks; offset-monitor dock still did not
render)
- budgie-panel --reset --replace (resolved unrelated panel layout
issues from upgraded 24.04 layout, did not affect either dock bug)
- All available apt updates installed
- Un-rotating DP-2 (transform normal) — did not affect Bug B
==============================================================
Stable workaround in use
- Single panel configuration (panel_2.conf disabled)
- Dock anchored to left edge of the monitor at desktop position (0,0)
- Intelligent auto-hide (visibility=2)
- Functions correctly; second monitor has no dock until fixed
==============================================================
Logs/output (every Crystal Dock launch, identical across all tests)
qt.svg: /usr/share/icons/Pocillo/64/apps/org.gnome.Nautilus.svg:
190:6: Could not resolve property: #linearGradient3999
LayerShellQt.Window.screenConfiguration is deprecated use screen
and wantsToBeOnActiveScreen instead
Could not find application with id: budgie-panel. The window icon
will have limited functionalities.
No output is produced when clicking on a non-functional dock — input
events do not appear to reach the process.
