Add an option to disable the following flag for virtual displays:
DisplayManager.VIRTUAL_DISPLAY_FLAG_DESTROY_CONTENT_ON_REMOVAL
With this option, when the virtual display is closed, the running apps
are moved to the main display rather than being destroyed.
PR #5615 <https://github.com/Genymobile/scrcpy/pull/5615>
On --no-vd-system-decoration, the boolean option must be set to false.
It was wrongly assigned from optarg (this worked because optarg is NULL
at this point, so it was converted to false).
PR #5615 <https://github.com/Genymobile/scrcpy/pull/5615>
When running scrcpy with --tcpip=xx.xx.xx.xx, to make sure a new working
connection is established, it was first disconnected by a call to:
adb disconnect <addr>
However, this caused all running instances connected to that address to
be killed. Running several instances of scrcpy on the same device is now
useful with virtual displays, so change the default behavior to NOT
disconnect.
To force a reconnection, a '+' prefix can be added:
scrcpy --tcpip=+192.168.0.x
Fixes#5562 <https://github.com/Genymobile/scrcpy/issues/5562>
For non-Windows portable builds, use the absolute path to the adb
executable located in the same directory as scrcpy.
On Windows, just use "adb", which is sufficient to use the local one.
PR #5560 <https://github.com/Genymobile/scrcpy/pull/5560>
Contrary to getenv(), the result of sc_get_env() is encoded in UTF-8 on
all platforms. Since it is allocated, it requires an explicit init() and
destroy() functions.
PR #5560 <https://github.com/Genymobile/scrcpy/pull/5560>
Contrary to getenv(), sc_get_env() returns an allocated string that is
guaranteed to be encoded in UTF-8 on all platforms (it uses _wgetenv()
internally on Windows and converts the strings).
PR #5560 <https://github.com/Genymobile/scrcpy/pull/5560>
On Windows, interrupting a socket with shutdown() does not wake up
accept() or read() calls, the socket must be closed.
Introduce a new macro constant SC_SOCKET_CLOSE_ON_INTERRUPT, distinct of
_WIN32, because Windows will not be the only platform exhibiting this
behavior.
Refs #5536 <https://github.com/Genymobile/scrcpy/issues/5536>
Allow capturing virtual displays at a lower resolution using
-m/--max-size.
In the original implementation in #5370, the virtual display size was
necessarily the same as the capture size. The --max-size value was only
allowed to determine the virtual display size when no explicit size was
provided.
Since the dpi was scaled down accordingly, it is often better to create
a virtual display at the target capture size directly. However, not
everything is rendered according to the virtual display DPI. For
example, a page in Firefox is rendered too big on small virtual
displays. Thus, it makes sense to be able create a virtual display at a
given size, and capture it at a lower resolution with --max-size. This
is now possible using OpenGL filters.
Therefore, change the behavior of --max-size for virtual displays:
- --max-size does not impact --new-display without size argument
anymore (the virtual display size is the main display size);
- it is used to limit the capture size (whether an explicit size is
provided or not).
This new behavior is consistent with main display capture.
Refs #5370 comment <https://github.com/Genymobile/scrcpy/pull/5370#issuecomment-2438944401>
Refs #5370 <https://github.com/Genymobile/scrcpy/pull/5370>
PR #5506 <https://github.com/Genymobile/scrcpy/pull/5506>
Add an option to disable the following flag for virtual displays:
DisplayManager.VIRTUAL_DISPLAY_FLAG_SHOULD_SHOW_SYSTEM_DECORATIONS
Some devices render a broken UI when this flag is enabled.
Fixes#5494 <https://github.com/Genymobile/scrcpy/issues/5494>
Deprecate --lock-video-orientation in favor of a more general option
--capture-orientation, which supports all possible orientations
(0, 90, 180, 270, flip0, flip90, flip180, flip270), and a "locked" flag
via a '@' prefix.
All the old "locked video orientations" are supported:
- --lock-video-orientation -> --capture-orientation=@
- --lock-video-orientation=0 -> --capture-orientation=@0
- --lock-video-orientation=90 -> --capture-orientation=@90
- --lock-video-orientation=180 -> --capture-orientation=@180
- --lock-video-orientation=270 -> --capture-orientation=@270
In addition, --capture-orientation can rotate/flip the display without
locking, so that it follows the physical device rotation.
For example:
scrcpy --capture-orientation=flip90
always flips and rotates the capture by 90° clockwise.
The arguments are consistent with --display-orientation and
--record-orientation and --orientation (which provide separate
client-side orientation settings).
Refs #4011 <https://github.com/Genymobile/scrcpy/issues/4011>
PR #5455 <https://github.com/Genymobile/scrcpy/pull/5455>
A call to swr_set_compensation() configures the resampler to drop or
duplicate "diff" samples over an interval of "distance" samples.
If the function is not called again, then after "distance" samples, no
more compensation will be applied. So it must always be called, even if
the new computed diff value happens to be the same as the previous one.
In practice, it is unlikely that the diff value is exactly the same
every second, except when it is actively clamped (to 2% of the sample
rate).
Reset video capture/encoding on MOD+Shift+r.
Like on device rotation, this starts a new encoding session which
produces a video stream starting by a key frame.
PR #5432 <https://github.com/Genymobile/scrcpy/pull/5432>
Accept a single boolean "on" rather than a "mode" (which, in practice,
could only take 2 values: NORMAL and OFF).
Also rename "screen power mode" to "display power".
PR #5418 <https://github.com/Genymobile/scrcpy/pull/5418>
If video playback is disabled, then SDK mouse (which uses absolute
positions) could not be used, so the default mouse mode was
automatically switched to UHID.
But UHID does not work on all devices, so it could make the whole scrcpy
session fail.
Instead, disable the mouse by default. It is still possible to pass -M
or --mouse=uhid to enable it explicitly.
Fixes#5410 <https://github.com/Genymobile/scrcpy/issues/5410>
By adding the '?' prefix, the app is searched by its name instead of its
package name (retrieving app names on the device may take some time):
scrcpy --start-app=?firefox
An app matches if its label starts with the given name,
case-insensitive.
If '+' is also passed to force-stop the app before starting, then the
prefixes must be in that order:
scrcpy --start-app=+?firefox
PR #5370 <https://github.com/Genymobile/scrcpy/pull/5370>
The previous commit introduced:
scrcpy --start-app=name
By adding a '+' prefix, the app is stopped beforehand:
scrcpy --start-app=+name
This may be useful to start a fresh app on a new virtual display:
scrcpy --new-display --start-app=+org.mozilla.firefox
PR #5370 <https://github.com/Genymobile/scrcpy/pull/5370>
Add a command line option --start-app=name to start an Android app by
its package name. For example:
scrcpy --start-app=org.mozilla.firefox
The app will be started on the correct target display:
scrcpy --new-display=1920x1080 --start-app=org.videolan.vlc
PR #5370 <https://github.com/Genymobile/scrcpy/pull/5370>
Co-authored-by: Simon Chan <1330321+yume-chan@users.noreply.github.com>
Add a feature to create a new (separate) virtual display instead of
mirroring the device screen:
scrcpy --new-display=1920x1080
scrcpy --new-display=1920x1080/420 # force 420 dpi
scrcpy --new-display # use the main display size and density
scrcpy --new-display -m1920 # scaled to fit a max size of 1920
scrcpy --new-display=/240 # use the main display size and 240 dpi
Fixes#1887 <https://github.com/Genymobile/scrcpy/issues/1887>
PR #5370 <https://github.com/Genymobile/scrcpy/pull/5370>
Co-authored-by: Simon Chan <1330321+yume-chan@users.noreply.github.com>
Co-authored-by: anirudhb <anirudhb@users.noreply.github.com>
The server params were passed from the main thread to the server thread,
so a deep copy was performed in case the caller instance was destroyed.
But in practice, it only contains memory that lives until the end of the
program (command line arguments), so simply reference it. Several copies
of string fields were missing anyway.
With the old macros definitions, the type of the result depended on the
type of `sec`.
In particular, if sec is a 32-bit type, sec * 1000000 was likely to
overflow (even if the result was assigned to a sc_tick by the caller of
the macro).
This was the case on Windows, where the long type is a 32-bit signed
integer: the --time-limit argument, expressed in seconds, was first
parsed to a long value, then multiplied by 1000000 by the
SC_TICK_FROM_SEC() macro, causing an overflow when the value was greater
than 2147 (2^31 / 1000000).
Fixes#5355 <https://github.com/Genymobile/scrcpy/issues/5355>
