To receive a notification on new releases, click on Watch > Custom > Releases on the top.

scrcpy v1.23

Changes since v1.22:

• Add HID/OTG support for Windows (--otg only) (#2773, #3011)
• Add HID/OTG support for macOS (#2774, #3031)
• Improve device selection (list devices, -d, -e) (#3005)
• Downscale and retry on MediaCodec error in more cases (#2990, #3043)
• Add ZSH completion script (#3012)
• Add Bash completion script (#2930, #3048)
• Add --no-cleanup option (#1764, #3020)
• Add --printf-fps (#468, #3030)
• Print both compiled and linked version of libs on --version
• Fix FPS counter (broken in v1.22)
• Various technical refactors and fixes

Highlights

HID/OTG on all platforms

Physical keyboard and mouse simulation (HID) was only available on Linux.

The previous release (v1.22) introduced a new OTG feature (--otg), to use the computer keyboard and mouse as if they were plugged directly to the device via an OTG cable, without mirroring and without requiring adb (USB debugging).

In v1.23, this feature is now also available on Windows (with some limitations) and macOS.

HID keyboard and mouse may be used either in "mirroring" mode (the default with mirroring enabled) or OTG mode (when --otg is passed):

# HID in mirroring mode
scrcpy --hid-keyboard --hid-mouse
scrcpy -KM  # the same, but using short options

# HID in OTG mode
scrcpy --otg --hid-keyboard --hid-mouse
scrcpy --otg -KM  # the same, but using short options
scrcpy --otg      # also the same, both keyboard and mouse are enabled if not specified

On Windows, it is not possible to open a USB device if it is already open by another process (like the adb daemon). As a consequence, we can't send HID events if adb is running. Therefore, HID in mirroring mode is not possible, only OTG mode is supported on Windows (and the adb daemon is killed before starting). See #3011.

EDIT: And there are still issues on Windows when USB debugging is disabled: #3050 😞

Also, due to an issue in the libusb prebuilt library for win32, this feature is disabled in the win32 release (it will be enabled later when it's fixed).

Also note that the mouse capture (when --hid-mouse is enabled) has some issues on macOS. A workaround for the main problem has been implemented, but you might need an additional click to get the mouse pointer back (see #3031).

Improve device selection

Until now, if several devices were connected, scrcpy failed with:

$ scrcpy
scrcpy 1.22 <https://github.com/Genymobile/scrcpy>
error: more than one device/emulator
ERROR: "adb get-serialno" returned with value 1
ERROR: Could not get device serial
ERROR: Server connection failed

This was not very user-friendly: the user had to call adb devices manually to get the serial, then call scrcpy -s xxxxxxxxxx explicitly.

This release introduces features to improve device selection (#3005).

If several devices are connected, scrcpy prints the list of devices:

$ scrcpy
…
ERROR: Multiple (3) ADB devices:
ERROR:     -->   (usb)  fedcba09                        device  GM1913
ERROR:     -->   (usb)  01234567890abcdef         unauthorized  
ERROR:     --> (tcpip)  192.168.1.1:5555                device  Nexus_5
ERROR: Select a device via -s (--serial), -d (--select-usb) or -e (--select-tcpip)
ERROR: Server connection failed

So it is possible to immediately call scrcpy again with -s.

In addition, two new options allow to select a USB or TCP/IP device when there is only one connected:

• -d (or --select-usb) uses a USB device (like adb -d)
• -e (or --select-tcpip) uses a TCP/IP device (like adb -e)

For example, to run scrcpy with the single TCP/IP device:

$ scrcpy -e
…
DEBUG: ADB device found:
DEBUG:           (usb)  fedcba09                        device  GM1913
DEBUG:           (usb)  05f5e60a0ae518e5          unauthorized  
DEBUG:     --> (tcpip)  192.168.1.1:5555                device  Nexus_5

To run scrcpy with a single USB device:

$ scrcpy -d
…
ERROR: Multiple (2) ADB devices over USB:
ERROR:     -->   (usb)  fedcba09                        device  GM1913
ERROR:     -->   (usb)  01234567890abcdef         unauthorized  
ERROR:         (tcpip)  192.168.1.1:5555                device  Nexus_5
ERROR: Select a device via -s (--serial), -d (--select-usb) or -e (--select-tcpip)
ERROR: Server connection failed

Since there are several devices connected over USB in this example, it fails, with a detailed error message.

In OTG mode, the USB devices are also listed for convenience:

$ scrcpy --otg
…
ERROR: Multiple (2) USB devices:
ERROR:     --> fedcba09           (xxxx:xxxx)  OnePlus SM8150-MTP
ERROR:     --> 01234567890abcdef  (xxxx:xxxx)  LGE Nexus 5
ERROR: Select a device via -s (--serial)

Bash and ZSH completion scripts

Scrcpy has a lot of options. For convenience, auto-completion scripts were added for Bash (#3048) and ZSH (@hltdev8642, #3012).

Auto-downscale on MediaCodec error

Some devices are not able to encode a video at the device screen definition. As a consequence, for many users, the first experience with scrcpy was just a failure with a MediaCodec exception.

To solve this problem, the previous release (v1.22) added a mechanism to catch MediaCodec errors on start and automatically retry with a lower definition (scrcpy -m1024).

However, MediaCodec may fail in different ways (#2990, #3043), and some of them were not catched. Now they are.

FPS counter

It was possible to log the capture framerate in the console (printed every second), by pressing MOD+i in the scrcpy window. It was broken in v1.22 (nobody reported it, so it's probably not widely used), it's fixed now.

This release adds a new option --print-fps to start the FPS counter immediately.

Note that a new frame is produced only when the device screen surface "changes", so it's expected to get a low framerate depending on what you do on the device. For example:

• if you play a 25 fps fullscreen video, then the capture framerate will not be higher than 25 fps;
• if nothing changes on your screen, then the capture framerate will be 0 fps.

Contact

Scrcpy now has a twitter account: @scrcpy_app
There is also a subreddit: r/scrcpy

This might sometimes be more appropriate than GitHub issues when it's not to report a bug.