Forward RCtrl to the device

[rom1v]

Only capture Left-Ctrl for scrcpy shortcuts, so that Right-Ctrl can be forwarded to the device.

Fixes #555

This allows for example to press Ctrl+t in Chrome to open a new tab (unfortunately, this shortcut does not work in Firefox) or to press Ctrl+c or Ctrl+d in Termux.

What do you think?

---

• scrcpy.exe
  SHA256: f07bb80ff82350a4b8d32bc6a00eeb9fc981a9c14bf7815018918dce09adb77c

(to be replaced in v1.14 release)

[leiserfg]

I think most of the users will prefer doing it in the other way (forward left-ctrl and use the right one for srccpy ).

[lilydjwg]

I prefer the reverse too: left-ctrl passed in, right-ctrl is for srccpy. Virtualbox works this way by default.

PS: Ctrl-T in the traditional Firefox for Android works. It doesn't work for Firefox Preview (which lacks a lot of features).

[rom1v]

Scrcpy is entirely controlled by Ctrl+key shortcuts, so I think it should use the main Ctrl key (left). IMO it would be surprising if scrcpy shortcuts didn't work with left Ctrl.

It's good to have a way to send Ctrl+shortcuts to the device, but IMO it's secondary compared to scrcpy shortcuts.

Virtualbox works this way by default.

IIRC, Virtualbox behaves differently: Right-Ctrl is the "host key", to be pressed alone to switch the "capture" mode. Here, it is used to inject shortcuts in the device.

[lilydjwg]

Scrcpy is entirely controlled by `Ctrl`+key shortcuts, so I think it should use the main `Ctrl` key (left). IMO it would be surprising if scrcpy shortcuts didn't work with left `Ctrl`. It's good to have a way to send `Ctrl`+shortcuts to the device, but IMO it's secondary compared to scrcpy shortcuts.

Well, maybe. Actually when I use scrcpy I don't even care about keyboards, partly because native shortcuts are not working well. I have two reasons to use scrcpy: 1. massive typing scenarios: I connect my keyboard to my phone via USB or bluetooth. 2. read-only view, e.g. as a remote camera.

> Virtualbox works this way by default. IIRC, Virtualbox behaves differently: Right-Ctrl is the "host key", to be pressed alone to switch the "capture" mode. Here, it is used to inject shortcuts in the device.

In Virtualbox you use right-ctrl to send keys to Virtualbox, not only to toggle "capture" mode.

[rom1v]

In Virtualbox you use right-ctrl to send keys to Virtualbox, not only to toggle "capture" mode.

Ok, I didn't know that. 👍

It's good to have a way to send Ctrl+shortcuts to the device, but IMO it's secondary compared to scrcpy shortcuts.

In fact, that's not necessarily true. When Ctrl shortcuts are available on the device, they might be used a lot (Ctrl+a to select all the text, Ctrl+t for a new tab, etc.), so it would make sense to consider them "the most important". So, in principle, using right-Ctrl for scrcpy shortcuts, and left-Ctrl for device shortcuts could be a good idea.

However, I'm especially annoyed with copy-paste shortcuts: if left-Ctrl is forwarded to the device, pressing left-Ctrl+c or left-Ctrl+v will just press Ctrl+c or Ctrl+v on the device (so for example it will not paste the computer clipboard, but the device clipboard).

We could make an exception for these shortcuts (and maybe some others), but it would be very confusing, since Ctrl+c could be used for other actions, like terminating a program (in Termux on the device).

In short, if I don't have a good solution for copy-paste, I think I still prefer right-Ctrl for device shortcuts and left-Ctrl for scrcpy shortcuts.

Of course, more opinions on the subject are welcome :)

[rom1v]

Another possibility could be to move all shortcuts from Ctrl to Meta (typically the "windows" key), and always forward both left and right Ctrl to the device.

Meta+c and Meta+v would be used to copy-paste between device and computer, while Ctrl+c and Ctrl+v would just be forwarded (not ideal, but at least it's clear).

EDIT: even better, we don't need a scrcpy shortcut to copy clipboard: every copy on the device is now automatically synchronized to the computer clipboard, so forwarding Ctrl+c on the device is sufficient. There would be Meta+v and Meta+Shift+v though. Too confusing?

This would also require to change the Ctrl+m and Ctrl+h shortcuts for macOS (#676 (comment) and #880). (any suggestions for replacing them?)

What do you think?

[rom1v]

To validate the behavior, I just implemented that in a branch: meta. Here is the list of the changes:

• all shortcuts now use the Meta key (the "Windows" key) instead of the Ctrl key, on all platforms
• Shift and Ctrl (both left and right) are forwarded to the device (that's very convenient to select text via Shift+arrows, Ctrl+a to select all, Ctrl+c to copy…)
• To copy a text, Ctrl+c works, because it is forwarded to the device, which, in a text field, copy the text into the clipboard… and the clipboard is now automatically (since v1.13) synchronized with the computer keyboard.
• Meta+c (the scrcpy shortcut coming from Ctrl+c) still exists: on Android < 7, it synchronizes the current keyboard, on Android >= 7, it presses COPY
• Meta+v and Meta+Shift+v still exist to copy respectively by injecting individual chars or by synchronizing keyboards and press PASTE (on Android >=7) (so they keep the same behavior)
• Meta+x has been added to press CUT (sending Ctrl+x to the device also works, but I think it's convenient and consistent to also expose it via a scrcpy shortcut, especially for macOS users, where Meta+x is the default shortcut for CUT)
• Therefore, I changed the "resize to fit" (the shortcut which removes the black borders) from Meta+x (oldly Ctrl+x) to Meta+w

What is not done yet:

• Meta+m and Meta+h have been left on macOS, but they are not usable (Use Cmd instead of Ctrl on macOS #676 (comment)). We need to change the letter for these shortcuts. Any suggestions?

Thank you for your feedbacks 😉

Binaries

For windows users, take both scrcpy.exe and scrcpy-server, and replace them in your scrcpy v1.14 release.

For other platforms, take scrcpy-server and build only the client.

• scrcpy.exe
  SHA256: dbef629f53bec1380086ff67ade588ca0852ccf13bc79f1d142ad6f23117fd48
• scrcpy-server
  SHA256: ded5317b47014d932dce088f2db75f89e6fa16694daab39c05635cc36a9b1441

[rom1v]

Oh, it can be simplified: we can synchronize the computer clipboard to the device clipboard any time the user presses Ctrl+v (before sending Ctrl+v to the device): b330ba4

That way, we can remove Meta+Shift+v.

So to summarize:

• Ctrl+c (in a text field) copies the selected text both to the device and computer clipboard
• Ctrl+x (in a text field) "cuts" the selected text and copies it both to the device and computer clipboard
• Ctrl+v copies computer clipboard to device clipboard and paste on the device (in a component where Ctrl+v pastes)
• Meta+v paste the text as a sequence of chars (must be kept, pasting the clipboard does not work in all cases on Android)

For now, there is still:

• Meta+c presses COPY (Android >= 7) and copies the device clipboard to the computer clipboard
• Meta+x presses CUT (Android >= 7)

But I think they could be removed.

[lilydjwg]

The Windows key is usually used for global things of the desktop environment, thus not passing into the application.

Ctrl+c (in a text field) copies the selected text both to the device and computer clipboard

But can scrcpy distinguish between a text field and a terminal? What about mouse/touch-initialized copy?

What about a tmux-style prefix scheme? Or other schemes that make the key used completely configurable so the user can tweak to avoid conflicts.

BTW in Linux a "meta" key means either a key that usually doesn't physically exist, or an Alt key. The Windows key and Command key is called Super.

[rom1v]

The Windows key is usually used for global things of the desktop environment, thus not passing into the application.

Do you have concrete exemples (in addition to Cmd+h and Cmd+m on macOS)?

What key would you suggest? Would Alt be better?

Ctrl+c (in a text field) copies the selected text both to the device and computer clipboard
But can scrcpy distinguish between a text field and a terminal?

In this branch, Ctrl is forwarded to the device, so on pressing Ctrl+c, the devices decides what to do. In a text field, it will copy the clipboard, in a terminal it will send SIGINT to the current command, etc. Whenever the device clipboard changes, it is synchronized to the computer clipboard.

What about mouse/touch-initialized copy?

If you copy by clicking on COPY on the device, it will change the device clipboard, so it will also be synchronized to the computer clipboard.

What about a tmux-style prefix scheme?

It's another possibility, but I think it's too bad to use an shortcut prefix to fullscreen or other stuff, whereas there are other keys available.

BTW in Linux a "meta" key means either a key that usually doesn't physically exist, or an Alt key. The Windows key and Command key is called Super.

👍 I will rename it to Super or Cmd.

[lilydjwg]

Do you have concrete exemples (in addition to Cmd+h and Cmd+m on macOS)?

e.g. I use super+c to close current window with the Awesome window manager (the default was super+shift+c). There is a lot of shortcuts on window managers that put an emphasis on keyboard accessibility.

What key would you suggest? Would Alt be better?

Alt is only a little better considering a lot of my zsh key bindings. Outside a terminal it should work great (not captured by local global shortcuts, not shadowing Android side keys). I suggest to make it configurable if feasible, e.g. let the user choose what combinations do what.

Whenever the device clipboard changes, it is synchronized to the computer clipboard.

That's great!

[leiserfg]

What do you think about allowing the users to config the key that will be used to control scrcpy, so one can pick the one that match better with his own workflow? So you can use left control as default for backward compatibility.

[rom1v]

The Windows key is usually used for global things of the desktop environment, thus not passing into the application.

You're right, on Windows, Win+r open the command popup.

I think I will forward left-Ctrl to the device, and use right-Ctrl for scrcpy shortcuts.

What do you think about allowing the users to config the key that will be used to control scrcpy, so one can pick the one that match better with his own workflow?

In theory, yes, but it's a lot of work: loading the config file at the right location for each platform, define the file format, parse it in C (which is awful for that task), execute the actions depending on the configuration...

I have no time to do that, and there are other priorities (for example, when I have more time, I would like to work on audio forwarding).

[elig0n]

The Windows key is usually used for global things of the desktop environment, thus not passing into the application.

This is entirely correct. In Windows 10 Win + R launches Run dialog , Win + D toggles showing the desktop, Win + L locks the screen, Windows+V the clipboard manager and there's plenty other letters already set by default by windows (https://support.microsoft.com/en-us/help/12445/windows-keyboard-shortcuts) so I would forget about that button for a modifier as it is almost 'hardwired' to the windows desktop environment and prone to cause trouble to Windows and Linux users alike as recent Linux DEs also started using them (and personally I also use set that modifier for DE actions).

I think I will forward left-Ctrl to the device, and use right-Ctrl for scrcpy shortcuts.

I support this fashion, in a way akin to how VirtualBox does it. I.e. keeping the underlying program controller keys from interfering with normal expected application interaction. The rational being is that back, home and other scrcpy actions comes second to and occur less often than the actual work on the app a user is interested in doing.

[lilydjwg]

BTW there are some Win-prefixed keys for Android too, e.g. Win+Enter -> Home screen, Win+Backspace -> Back, Win+N -> Notifications, Win+/ -> show the Keyboard shortcut list (it displays as a search icon, but Win key triggers it).

[rom1v]

I think I will forward left-Ctrl to the device, and use right-Ctrl for scrcpy shortcuts.

I just did that in #1465.

Feedback welcome there 😉

[rom1v]

@elig0n @leiserfg @lilydjwg I'm interested in your feedback on #1465 :)

[Helaer]

Some of the company's windows laptops do not have the Rctrl key. What should I do?

[elig0n]

Some of the company's windows laptops do not have the Rctrl key. What should I do?

You can use AutoHotKey to bind it to another key

[rom1v]

Here is a new proposal: #1598