I narrowed it down to a running instance of a TigerVNC client with the option "Send primary selection and cut buffer as clipboard" enabled.
The current implementation of that option basically changes the local clipboard behavior for ALL local applications as well, which seems a bit presumptuous (and annoying). I can understand if the vnc client does the selection->clipboard sync IF a paste is actually carried out inside the vnc window, but not when the copy/paste/selection has nothing to do with vnc.
Regards,
Raman
On Sat, 12 Sep 2015 10:27:15 -0700 (PDT)
rocke...@gmail.com wrote:
> The current implementation of that option basically changes the local
> clipboard behavior for ALL local applications as well, which seems a
> bit presumptuous (and annoying). I can understand if the vnc client
> does the selection->clipboard sync IF a paste is actually carried out
> inside the vnc window, but not when the copy/paste/selection has
> nothing to do with vnc.
>
Indeed, the VNC client doesn't touch your clipboard for outgoing
events. So it sounds like something inside your VNC session is bouncing
the clipboard data back. Perhaps you have a misbehaving clipboard
manager inside the VNC session?
You can get some more log output if you start the client with the
arguments -Log *:stderr:100. You should see both incoming and outgoing
clipboard events at that point. Selecting something locally should
result in an outgoing event, but not an incoming one.