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

Added support for utf8 clipboard based on TigerVNC/TightVNC extension #28

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

egorksv
Copy link

@egorksv egorksv commented Aug 21, 2022

No description provided.

@egorksv egorksv changed the title Added support for utf8 clipboard Added support for utf8 clipboard based on TigerVNC/TightVNC extension Aug 21, 2022
@egorksv
Copy link
Author

egorksv commented Aug 21, 2022

Hi @shinyhut - I'm a bit confused with GitHub UI, as I'm not using it much. I could not find an option to delete the previous PR (#27), would greatly appreciate it you could close that one.

@shinyhut
Copy link
Owner

Hi @egorksv, did you know the extended clipboard pseudo encoding is pretty well documented at https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#extended-clipboard-pseudo-encoding? It looks to me as if we're missing the part where the client should send an extended ClientCutText caps message indicating we only support the provide operation, text format and our maximum text length (make this configurable).

I suspect not sending that message is why you're having to handle error cases where the server sends unsupported message types and messages that are too long (it defaults to "text, rtf, html, request, notify and provide and a maximum size of 20 MiB").

@egorksv
Copy link
Author

egorksv commented Aug 31, 2022

Hi Paul, that's awesome find! Somehow missed it in the crunch of our project development.

The code here is based on UltraVNC/TigerVNC C++ implementation (https://github.com/TigerVNC/tigervnc/pull/834/files#diff-3708dc882e492835643384e30efa3d98c2b9296612fc705bd179ba2a6f9a74e9) as TigerVNC is what we're using on the server side, with similar error cases / invalid message types.

I'll need to confirm whether I'll be allocated additional project time to add client caps feature - however, additional error handling can never be too bad.

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

Successfully merging this pull request may close these issues.

None yet

2 participants