Bugzilla – Bug 5772
server clipboard needs external process (vncconfig) to function
Last modified: 2016-12-05 15:01:32
You need to
before you can comment on or make changes to this bug.
The clipboard in Xvnc does not work without vncconfig running. It was probably
done this way because it was the most obvious way to do it, given how X11
clipboard works. But that doesn't mean it's a simpler way of doing, as evident
by the fact that there are still magical hooks in Xvnc to help vncconfig, and
there is a new "VNC" extension to X11 to handle the clipboard data transfer.
It would probably be better if the clipboard was handled entirely inside Xvnc.
It will still be a moderately complex system though as the X server has poor
support for handling windows that are created internally. But it should at
least all the code can then be in one place, and it should be more robust as
there is just a single process handling things.
An attempt at this here:
Tester should verify that the clipboard transfer works well in both directions
with various clipboard implementations. I.e. should try a GTK+ application, Qt
application, Java application, etc.
- Control of clipboard
- Disable using SendCutText and AcceptCutText arguments to Xvnc
- Changing above properties with vncconfig
- Disable change of above properties from vncconfig (Xvnc argument
- Control of max clipboard buffer size
- Normal use of primary and clipboard with different toolkits
Teseted using ThinLinc server and client build 5200, also tested new client
against old server.
> - Control of clipboard
> - Disable using SendCutText and AcceptCutText arguments to Xvnc
Works as expected, tested defaults values, and manual enable/disable
> - Changing above properties with vncconfig
Works as expected, changed the settings live using vncconfig from within a
> - Disable change of above properties from vncconfig (Xvnc argument
Adding -noclipboard to Xvnc arguments, vncconfig fails to change the properties
> - Control of max clipboard buffer size
Work as described. However only affects the size while copying into a vnc
session and not out from the session.
> - Normal use of primary and clipboard with different toolkits
Tested clipboard transfers from within a session to desktop and vice versa,
using application gedit (GTK), kate (QT), jedit (JAVA). Works as expected
except for strange inconsitency while using gtk application server side .
 While using gedit in a session and copies cyrillic text (russian) and then
pastes ib the desktop, the string is escaped \n044b\n.... but when copying
from gedit on desktop side and paste into server, ???? is shown instead of
escaped chars. Also when using non GTK application server side, all pastes are
not escaped and ??? is shown.
(In reply to comment #6)
>  While using gedit in a session and copies cyrillic text (russian) and then
> pastes ib the desktop, the string is escaped \n044b\n.... but when copying
> from gedit on desktop side and paste into server, ???? is shown instead of
> escaped chars. Also when using non GTK application server side, all pastes are
> not escaped and ??? is shown.
This depends on who does the conversion. VNC only handles latin-1, so we prefer
that if possible. GTK will often convert for us using the \uxxxx notation.
Other programs might not though, in which case we ask for UTF-8 data and do the
conversion ourselves. We have a very simple implementation right now that just
replaces unsupported characters with '?'.
It's further complicated by the fact that we use FLTK for clipboard and
conversion on the client, which might behave differently from our
implementation in Xvnc. Some convergence of this is done in the prototype for
bug 3895, but if we fix that bug then we'll have proper unicode support anyway.
Work as expected, closing.