Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Doesn't work with TightVNC's UTF-8 clipboard support #592

Open
felixonmars opened this issue Aug 29, 2023 · 2 comments
Open

Doesn't work with TightVNC's UTF-8 clipboard support #592

felixonmars opened this issue Aug 29, 2023 · 2 comments
Assignees
Labels

Comments

@felixonmars
Copy link

Describe the bug
When connecting to a TightVNC server, clipboard sync is still in latin-1 and ends up with question marks or garbage text.

To Reproduce
Connect to a TightVNC server, and try to copy unicode text from or to the remote device.

Expected Behavior
Unicode text remains the same across clipboards.

Logs/Backtraces
n/a

Your environment (please complete the following information):

  • OS and version: Arch Linux x86_64, remmina or krdc with libvncserver 0.9.14
  • Compiler and version: GCC 13.2.1

Additional context
TightVNC supports UTF-8 since version 2.8.53. Copied from its changelog:

Added support for Unicode clipboard transfers (UTF-8). The latest public version of the standard RFB protocol (3.8) does not support Unicode text, so we implemented this via a new TightVNC protocol extension. This feature will work when supported at both ends of the connection.

So probably an additional protocol extension is needed for this?

I have looked through its source code and found something that should be related:
2023-08-28-22-11-57

@layercak3
Copy link

libvncserver and tigervnc implements the Extended Clipboard pseudo-encoding (from UltraVNC in 2010) which supports UTF-8. It looks like tightvnc has introduced yet another cut-text protocol. The Extended Clipboard pseudo-encoding does not introduce new client/server message numbers like in the screenshot, but instead modifies the behaviour of 3/6.

@bk138
Copy link
Member

bk138 commented Jul 3, 2024

Hi @felixonmars, does #561 change/fix this for you?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants