search

TurboVNC / turbovnc

Main TurboVNC repository
https://TurboVNC.org
GNU General Public License v2.0
773 stars 139 forks source link

clipboard problem on the remote end #192

Closed jave closed 5 years ago

jave commented 5 years ago

I am having trouble copying text on the remote server.

I tried copying betweenseveral different applications.

I notice there are several similar issues in the bugtracker, but they seemed not relevant for this. I apologize if I missunderstood.

jave commented 5 years ago

I tried switching the server WM to xfce4 on a whim, and that didnt help

dcommander commented 5 years ago

I can't reproduce the issue. Any chance that you are using a Wayland session and this goes away when you switch to an Xorg session (on the client side)?

dcommander commented 5 years ago

And just to clarify, how are you trying to copy the text from client to server?

jave commented 5 years ago

However:

jave commented 5 years ago

on another whim, I tried jre-12 on the client side for the turbovnc client, but it made no difference.

Also I tried poking around with xsel, but didnt figure anything out.

jave commented 5 years ago

another data point:

When I select something in any application on the remote, the selection goes away after a short while. This doesnt happen on the client machine.

Attempt att clarification:

dcommander commented 5 years ago

Can you try upgrading the server RPM to the 2.2.x stable pre-release build? https://turbovnc.org/DeveloperInfo/PreReleases

jave commented 5 years ago

2.2.3 didnt help

jave commented 5 years ago

tried 2.2.80, that didnt help either. On the server side.

dcommander commented 5 years ago

I unfortunately cannot reproduce the issue. Are there any messages displayed on the TurboVNC Viewer command line or in the TurboVNC Server log that might give me a clue?

jave commented 5 years ago

Client log(nothing relevan AFAICS)

/opt/TurboVNC/bin/vncviewer -ExtSSH=1 -Tunnel=1 tanaka:1 libjawt.so path: /usr/lib/jvm/jre-12/lib CConn: connected to host localhost port 39091 CConnection: Server supports RFB protocol version 3.8 CConnection: Using RFB protocol version 3.8 CConn: Using pixel format depth 24 (32bpp) little-endian rgb888 CConn: Requesting Tight encoding TurboVNC Helper: Enabling X11 full-screen mode for window 0x04000039 TurboVNC Helper: Grabbed keyboard & pointer for window 0x04000039 CConn: Enabling GII TurboVNC Helper: Listening for XInput events on :0 (window 0x04000039) Viewport: Successfully created device 1 (Wacom HID 481C Pen stylus) Viewport: Successfully created device 2 (Wacom HID 481C Finger touch) Viewport: Successfully created device 3 (Wacom HID 481C Pen eraser) CConn: Enabling continuous updates TurboVNC Helper: Ungrabbed keyboard & pointer TurboVNC Helper: Shutting down XInput listener on display :0 TurboVNC Helper: Disabling X11 full-screen mode for window 0x0400010a TurboVNC Helper: Listening for XInput events on :0 (window 0x0400010a) Viewport: Successfully created device 1 (Wacom HID 481C Pen stylus) Viewport: Successfully created device 2 (Wacom HID 481C Finger touch) Viewport: Successfully created device 3 (Wacom HID 481C Pen eraser)

dcommander commented 5 years ago

Anything in the server log? Does this happen with any arbitrary text? Does it happen without SSH tunneling? Have you tried upgrading the client RPM to the 2.2.3 pre-release as well?

jave commented 5 years ago
jave commented 5 years ago

Ok, I tried running vncviewer inside a x2go session, which in that case doesnt use ssh at all. Same thing.

Then I tried copy/paste inside the x2go remote session, and, its the same issue.

I find this completely weird.

x2go has its own X stack just as turbovnc.

Do you have a pointer to a document that describes how the different clipboard parts are supposed to work together? Because at this point I'm kind of baffled.

dcommander commented 5 years ago

So the issue is reproducible in x2go independently of TurboVNC? Have you tried a different client machine? I don't know much about how x2go works, but you are correct that it uses a completely different X server code base than TurboVNC, and it most likely implements clipboard handling on the server side in a completely different way. That's why I'm wondering aloud whether this might be a client-side issue-- perhaps some daemon or other program interfering with the clipboard on the client?

Googling clipboard handling x11 pops up a few good blog posts with descriptions and examples of how X11 clipboard handling normally works. The basic concepts are:

  1. There are two clipboards, PRIMARY (normally activated with the middle mouse button) and CLIPBOARD (normally activated with Ctrl-C/Ctrl-V or the Cut/Copy/Paste menu items in an application.)
  2. The current contents of a particular clipboard are stored in an X window property ("atom.") The window in which those contents are stored is called the "selection owner."
  3. An X11 application queries the contents of one of those clipboards by:
    • calling XConvertSelection() to transfer the clipboard contents from its "owner" window to an X window property in a "target" window controlled by the calling application, then
    • calling XGetWindowProperty() to query the "target" window property into which the clipboard contents were transferred.
  4. An X11 application modifies one of those clipboards by:
    • calling XSetSelectionOwner() to assign ownership of the clipboard to a window controlled by the calling application, then
    • calling XChangeProperty() to modify the X window property, in the new "owner" window, corresponding to the clipboard.
  5. When XConvertSelection() is called:
    • If there is no current owner for the requested clipboard, then the X server generates a SelectionNotify event to notify the requesting application of that fact.
    • If the requested clipboard has an owner, then the X server generates a SelectionRequest event to notify the owner. The application controlling the owner window is then responsible for converting the clipboard to the requested format and sending a SelectionNotify event to the target window/requesting application.

See also: https://tronche.com/gui/x/xlib/window-information/selection.html https://www.x.org/releases/X11R7.6/doc/xproto/x11protocol.html

The TurboVNC Server uses an in-tree Xorg code base, so we patch the Xorg code such that, if a SelectionNotify event occurs, vncHandleSelection() (in vnc/unix/Xvnc/programs/Xserver/hw/vnc/cutpaste.c) is called. That function takes care of sending the clipboard from server to viewer, using the ServerCutText RFB message. If a clipboard update is received from the viewer (via the ClientCutText RFB message), then vncClientCutText() (also in vnc/unix/Xvnc/programs/Xserver/hw/vnc/cutpaste.c) is called after the clipboard update is received. That function changes the clipboard owner (by default, it changes the owner for both PRIMARY and CLIPBOARD) to a tiny invisible window controlled by the TurboVNC Server code and then sets the relevant X window properties in that window to reflect the new clipboard contents from the client machine.

Note that the PRIMARY and CLIPBOARD clipboards are independent, so it would be a good data point to know whether middle-mouse-button pasting works in GEdit or whether the issue is only affecting Ctrl-C/Ctrl-V.

dcommander commented 5 years ago

Something else you could try, in order to verify whether the issue is client-side, is to start the TurboVNC Server with -noclipboardrecv -noclipboardsend and start the TurboVNC Viewer with -norecvclipboard -nosendclipboard. That will completely disable clipboard synchronization on both ends, and if the problem goes away, then that means that the problem is on the client end.

jave commented 5 years ago

For some reason something called "clipit" was installed on the server, either by default or as a dependency.

Anyway, I removed this thing, and now I can copy paste!