Last time, I wrote about wrestling with the Ubuntu display server, Wayland, to get a clipboard manager working. This involved a lot of research and fiddling with settings I'd forgotten existed.
So we're coming back to this (and this series is building to a point, I promise) because important keyboard shortcuts weren't working, and I couldn't figure out why.
Again, for credit - I used ChatGPT and Claude to help investigate everything, as well as lots of The Internet of course.
The setup
Specifically, I noticed that Ctrl+Shift+V (paste without formatting) had stopped working - nothing happened at all. Right-clicking and selecting "Paste without formatting" from the menu worked fine, so the clipboard itself was functioning correctly.
None of the obvious things seemed to work, so in we go.
Tally ho
Yeah so clearly something had broken - presumably something was capturing the keyboard event somewhere. But where to start? I can debug Ubuntu, but it's not a forte of mine so let's start with Claude.
According to Claude, the first suspect was IBus, Ubuntu's input method framework, which is known to grab Ctrl+Shift+V for Unicode character entry. Killing the IBus daemon ruled it out.
Next I checked GNOME's built-in keyboard shortcuts using gsettings:
gsettings list-recursively | grep -i "ctrl.*shift.*v\|<Primary><Shift>v"
gsettings list-recursively org.gnome.shell.keybindings | grep -i shift
gsettings list-recursively org.gnome.settings-daemon.plugins.media-keys | grep -i shift
Lo and behold - nothing useful came back.
A test in Firefox showed this wasn't a Chrome anomaly, which made it likely the interception was happening at the OS level, not in the browser.
So where is it?
Claude had me go looking for a running clipboard manager (which was odd, since it knew GPaste was running having just helped me get it working) but a process grep "revealed" GPaste (shock):
ps aux | grep -iE "copyq|gpaste|autokey|xbindkeys|keyd|espanso|ulauncher|albert"
GPaste does grab paste-related shortcuts, although I'd previously manually checked through the shortcuts. Re-inspecting its own settings showed Ctrl+Shift+V wasn't listed there.
The real breakthrough came from using wev, a Wayland event viewer:
wev | grep -A2 "sym\|state"
This showed that when pressing Ctrl+Shift+V, the V key only ever produced a release event, never a press. Something was consuming the keypress at the GNOME Shell level, before it ever reached Wayland or the browser.
Claude went back to GPaste at this point, and the GPaste GNOME Shell extension. It does operate at exactly that level, but disabling it and logging out didn't fix the problem - the keydown event was still being swallowed.
No really, where is it?
A final breakthrough came from querying dconf directly, which shows much lower level configuration than gsettings:
dconf dump / | grep -i "shift.*v\|ctrl.*v" | grep -iv "audio\|volume\|XF86"
This revealed a custom keybinding with Ctrl+Shift+V. Inspecting it further:
dconf dump / | grep -B5 "Shift><Control>v"
dconf dump /org/gnome/settings-daemon/plugins/media-keys/custom-keybindings/custom0/
Showed this:
binding='<Shift><Control>v'
command='/usr/bin/diodon'
name='Diodon'
Oh hello Diodon - you're still here. Apparently, despite being uninstalled months ago, my old clipboard manager did not clear up properly when it was uninstalled. Or possibly I'd written an extra shortcut and forgotten? Either way, there was a leftover GNOME keybinding, orphaned but causing problems. The binary was gone, so the shortcut did absolutely nothing, but it was still intercepting the keypress at the Shell level and swallowing it.
Execute Order 66
dconf reset -f /org/gnome/settings-daemon/plugins/media-keys/custom-keybindings/custom0/
One command, instant fix, no restart required.
Conclusion
This was interesting. I did essentially end up editing the blasted registry again, which is a really poor state of affairs and as I said before, something I thought Linux had moved past. But here we are.
More interesting was the journey Claude and I went on together. I could have debugged this myself, but this isn't information I retain in my brain, so I'd have been looking everything up. By letting Claude take the lead, the investigation was certainly quicker, but also took a very different path.
Instead of methodically isolating the exact place where the keypress event was being intercepted, I would have gone to dconf sooner, and without a detour through gsettings. I'd have used my experience and intuition to bypass some stages of diagnosis. If I remembered all the relevant commands, that probably would have been quicker.
That said, if that intuitive guess had proven wrong I'd have been much more lost. I hadn't used wev before, so I'd have been starting from scratch entirely there. Plus I actually fixed this alongside doing something else, whereas working solo would have required direct focus and likely I'd have put it off for much longer.
So was Claude helpful here? Undoubtedly yes, but not quite in the way I expected - and here we are getting to the point of this trilogy (oh yes - there is a point) which is about how we work collaboratively with AI, and how we learn through this process. But that's next time!
This post is part of a series:
