Description of problem: When I connected to vncserver with command `vncviewer example:1` then I am not able to copy from client clipboard to server. But when I connect to vncserver with command `vncviewer` and fill 'examle:1' to gui, clipboard working. Version-Release number of selected component (if applicable): tigervnc-1.2.80-0.8.20130124svn5036.fc18.x86_64 tigervnc-server-1.2.80-0.8.20130124svn5036.fc18.x86_64 How reproducible: Always Steps to Reproduce: 1. start vncserver on remote pc 2. connect to remote pc with `vncviewer remote_pc:1` 3. copy text from pc with client 4. paste text to vncviewer window Actual results: server clipboard is pasted Expected results: text from clipboard is pasted to server Additional info:
... same here with several machines running Fedora 18. All possible combinations of clipboard options always fail in pasting the clipboard to the server. It is a very nasty bug for day-to-day use of vncviewer.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
... the bug is still there in Fedora 19 and Fedora 20 as well.Please keep it open. Actually in the latest versions copy and paste works from some applications but not from others (for example xterm and emacs). Again in the past it used to work from whichever applications as it should be.
I can confirm this problem on latest Fedora 20 as well. tigervnc-1.3.0-7.fc20.x86_64 fltk-1.3.2-1.fc20.x86_64 Googl'ing on this topic shows previous discussions, for example http://sourceforge.net/p/tigervnc/bug-tracker/122/ https://www.mail-archive.com/tigervnc-users@lists.sourceforge.net/msg00628.html some of which suggest there are/have-been issues with either/both TigerVNC and FLTK, which is why I included the versions for both above. However from what I can tell, the versions above are the latest. I remember reading a couple posts (from Pierre Ossman, IIRC) that questioned whether Fedora's FLTK contains all the necessary patches, but I believe the versions shown above are the latest. I first encountered this issue upgrading my lap-top from F14, where copy-paste worked (mostly) fine, to F20. In most cases, when I select something on the client (local session) side, KDE's Klipper running in the VNC session on a remote machine (F17 in this particular case) is at first very slow to open, and when it finally does, it shows an empty entry instead of the text I selected. Some posters have described this as a blank line; for me it's empty. I'd say that every once in a while my text selection does get through to the server - maybe I'm dreaming... :)
One additional detail... When using the F20 viewer connected to the remote F17 session (KDE with Klipper running on both sides), if I leave the "Accept clipboard from viewers" option enabled in VNC Config on the remote/server side, sometimes I can't even copy-paste successfully _within_ the VNC session. I'll select something but nothing pastes, and I notice the highlight on the selection goes away immediately; when I try look at Klipper's contents in the remote session, I get the same behaviour as when I select something on the local side - ie, a long delay opening the list, and the "current" (top) item is empty. It's as if the local session over-writes the remote as soon as it's aware that something was selected on the remote side. If I disable "Accept clipboard from viewers", copy-paste within the VNC session works as expected. (But then I can't copy anything from the local session to the remote one, of course.)
Following the mail-archive thread mentioned in comment 6, I came to this post from Brian Hinz https://www.mail-archive.com/tigervnc-users@lists.sourceforge.net/msg00676.html which requests testing a nightly TigerVNC build. That was last September; I downloaded the current nightly cross-compatible build for x86_64 http://www.tigervnc.org/tiger.nightly/xc/x86_64/tigervnc-Linux-x86_64-1.3.80-20140112svn5157.tar.gz unloaded the archive, and executed the vncviewer in-place. It works for me -- in a very quick test I was able to copy-paste text in both directions again. :) (Klipper in the server session still exhibits its slow opens when I copy something, but I imagine that to be a completely different issue.) So from the sound of things there may still be patches missing from Fedora's version of FLTK. The latest bug (mentioned in that thread anyway) that affected xterm was fixed by Pierre Ossman on 2013-09-05.
(In reply to Don Estabrook from comment #8) Thanks, Don. That vncviewer build does indeed resolve the long standing pasting issue for me. I was about to try another linux but now I can move on from F17.
Minor update: Now that a month or so has passed, I have these versions: tigervnc-1.3.0-12.fc20.x86_64 fltk-1.3.2-3.fc20.x86_64 Pasting through VNC still doesn't work, so I'm continuing to use the nightly TigerVNC build mentioned in comment 8 as a work-around. I'm not sure I understand how the FESCo policy issue plays here - I mean it makes sense to me that all packages which use a library should use use the same one, but I'm wondering why Pierre Ossman's fixes have apparently not gotten into the common version of fltk. (If that's indeed the problem...) So by my way of thinking, TigerVNC shouldn't _need_ its own private forked version of the lib, should it? Do we just need the packager of fltk for Fedora to make sure it's completely up-to-date, or is there something else going on here? After a month of using the work-around I'm rather more confident that the weirdness I was seeing with KDE's Klipper (comment 6 and 7) is most likely related to Klipper itself rather than VNC. Seems two of them (one in the VNC session (server side) and one locally on the machine running the viewer) don't play well together. I have to shut one of them down to avoid problems, which I don't remember having to do in the past.
(In reply to Don Estabrook from comment #10) > So by my way of thinking, TigerVNC shouldn't _need_ its own private forked > version of the lib, should it? No, it shouldn't. It really looks like the fltk package must be missing something from STR #2599 or STR #2636, although I can't see what. Changing component to fltk.
Looks like upstream http://www.fltk.org/str.php?L2636 indeed has a fresher patch available there. I'll look into integrating that one for testing.
http://koji.fedoraproject.org/koji/taskinfo?taskID=6565060 f20 scratch build with updated clipboard patch. (I'm regretting our carrying so many non-upstreamed patches... tried rebasing to 1.3.x-r10109 snapshot, and that's a mess right now)
please test scratch build from comment #13 , any feedback (good or bad) is welcome.
Tested on two machines (fedora 20 fully updated + fltk-1.3.2-4.fc20.x86_64 from koji). It works!!! Thanks a lot....
ok, working on f20 update. based on comment #5 apparently f19 is affected too... any objections to merging 1.3.2-4 back to f19 branch too?
fltk-1.3.2-4.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/fltk-1.3.2-4.fc20
Package fltk-1.3.2-4.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing fltk-1.3.2-4.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-3119/fltk-1.3.2-4.fc20 then log in and leave karma (feedback).
Works for me! Thanks for the fix. I'm able to copy and paste between the vnc window and the host system.
fltk-1.3.2-4.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/fltk-1.3.2-4.fc19
fltk-1.3.2-4.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
fltk-1.3.2-4.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.