Client takes over synchronizing my selection and clipboard buffers?

81 views
Skip to first unread message

rocke...@gmail.com

unread,
Sep 12, 2015, 1:27:15 PM9/12/15
to TigerVNC User Discussion/Support
I am running TigerVNC on Fedora 21, version 1.4.3 release 3-fc21. I had a strange problem -- my X selection buffer was being copied to my X clipboard buffer automatically, even though my clipboard manager (Klipper) was set not to do this.

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

Pierre Ossman

unread,
Sep 18, 2015, 3:27:48 AM9/18/15
to rocke...@gmail.com, TigerVNC User Discussion/Support
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.

Rgds
--
Pierre Ossman Software Development
Cendio AB http://cendio.com
Teknikringen 8 http://twitter.com/ThinLinc
583 30 Linköping http://facebook.com/ThinLinc
Phone: +46-13-214600 http://plus.google.com/+CendioThinLinc

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Raman Gupta

unread,
Sep 18, 2015, 4:15:51 PM9/18/15
to TigerVNC User Discussion/Support, rocke...@gmail.com
On Friday, September 18, 2015 at 3:27:48 AM UTC-4, Pierre Ossman wrote:
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.

You're right, that is exactly what is happening. When I select some text locally, vnc sends the clipboard data, which then bounces back:

Fri Sep 18 13:02:30 2015
 Viewport:    Sending clipboard data (394 bytes)
 CConn:       Got clipboard data (448 bytes)

However, I have no idea why the remote is bouncing the event back. Its just a standard Windows 7 box. It doesn't have any custom clipboard manager installed as far as I know. The remote VNC is TightVNC 2.0.7 -- old I know, and checking the changelog it seems a bunch of changes were made to TightVNC clipboard handling just before this version. Next step: update TightVNC and try again!

Thanks for your help!
Raman

Reply all
Reply to author
Forward
0 new messages