You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Modifying the keycodes associated to control keys on the remote host (Ubuntu + Xfce4) makes clipboard sync from local (MacOS) to remote (Linux) stop working; remote to local clipboard sync keeps working.
I decided to change the keycodes so that I can keep my mac shortcuts when on the remote (Cmd_L can still be used to do Cmd+C, Cmd+V, etc.; Option_L can be used as Alt_L on Linux). The change allows me to keep my workflow without switching shortcuts from one machine to another.
with dbus-x11 installed and lightdm as session manager,
Edit /usr/share/X11/xkb/keycodes/evdev; Replace the keycodes for and for another keycode of your choice (for me it was 105 and 64 respectively, using a Logi MX Mini keyboard).
Save the file, run setxkbmap to update the keymap
Logout
Reconnect to the remote
Attempt to copy from local (MacOS) to remote - Notice that the clipboard is not sent over
Attempt on the remote to copy some content (e.g. from a notepad like app like Mousepad or Gedit) and paste (copy and paste on the remote) - see that the new keyboard mapping works as intended
Attempt on the local to paste - see that the clipboard content of the remote has been copied back to the local clipboard.
(I confirm the clipboard works locally from local to local)
Expected behavior
Clipboard should work both ways if Options > Input > Accept clipboard from server and Options > Input > Send clipboard to server are checked.
Especially since the change in keymapping is done on the remote, not the local??
Two ways to go about it:
Determine and fix the source of current bug
(Or to achieve my desired result of having the same keyboard shortcuts as on my Mac): Support ability to remap key strokes sent to the remote (maybe directly use an .Xmodmap?)
Screenshots
N/A
Client (please complete the following information):
Server (please complete the following information):
OS: Ubuntu 24.04 lts stable
VNC server: x11vnc
VNC server version: 0.9.16 lastmod: 2019-01-05
Server downloaded from: apt index (sudo apt install x11vnc)
Server was started using: {above command}, as a service via systemctl
X11 session manager: lightdm
X11 session manager version: 1.30.0
X11 session manager was started using: /bin/sh -c [ "$(basename $(cat /etc/X11/default-display-manager 2>/dev/null))" = "lightdm" ] as a service via systemctl
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered:
Describe the bug
Modifying the keycodes associated to control keys on the remote host (Ubuntu + Xfce4) makes clipboard sync from local (MacOS) to remote (Linux) stop working; remote to local clipboard sync keeps working.
I decided to change the keycodes so that I can keep my mac shortcuts when on the remote (Cmd_L can still be used to do Cmd+C, Cmd+V, etc.; Option_L can be used as Alt_L on Linux). The change allows me to keep my workflow without switching shortcuts from one machine to another.
To Reproduce
Steps to reproduce the behavior:
Given an X11 session on remote:
with dbus-x11 installed and lightdm as session manager,
/usr/share/X11/xkb/keycodes/evdev
; Replace the keycodes for and for another keycode of your choice (for me it was 105 and 64 respectively, using a Logi MX Mini keyboard).(I confirm the clipboard works locally from local to local)
Expected behavior
Clipboard should work both ways if Options > Input > Accept clipboard from server and Options > Input > Send clipboard to server are checked.
Especially since the change in keymapping is done on the remote, not the local??
Two ways to go about it:
Screenshots
N/A
Client (please complete the following information):
Server (please complete the following information):
sudo apt install x11vnc
)/bin/sh -c [ "$(basename $(cat /etc/X11/default-display-manager 2>/dev/null))" = "lightdm" ]
as a service via systemctlAdditional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: