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 --orientation (which provides a
separate client-side orientation).
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>
Initialize UHID devices with a custom name:
- "scrcpy: $GAMEPAD_NAME" for gamepads
- "scrcpy" for keyboard and mouse (or if no gamepad name is available)
The name may appear in Android apps.
PR #5270 <https://github.com/Genymobile/scrcpy/pull/5270>
This message will be sent on gamepad disconnection.
Contrary to keyboard and mouse devices, which are registered once and
unregistered when scrcpy exists, each physical gamepad is mapped with
its own HID id, and they can be plugged and unplugged dynamically.
PR #5270 <https://github.com/Genymobile/scrcpy/pull/5270>
Many parsing and formatting C functions like strtof() and asprintf() are
locale-dependent. Forcing a C locale just for the conversions in a way
that works on all platforms is a mess.
In practice, this is not a problem, scrcpy always uses the C locale,
because it never calls:
setlocale(LC_ALL, "");
But the max-fps option should not depend on the locale configuration
anyway.
Since the value is parsed by the client in Java anyway, just forward the
string value as is.
Restrict shortcut modifiers to be composed of only one item each.
Before, it was possible to select a list of multiple combinations of
modifier keys, like --shortcut-mod='lctrl+lalt,rctrl+rsuper', meaning
that shortcuts would be triggered either by LCtrl+LAlt+key or
RCtrl+RSuper+key.
This was overly generic, probably not used very much, and it prevents to
solve inconsistencies between UP and DOWN events of modifier keys sent
to the device.
Refs #4732 <https://github.com/Genymobile/scrcpy/issues/4732>
PR #4741 <https://github.com/Genymobile/scrcpy/pull/4741>
The keyboard settings can be opened by:
adb shell am start -a android.settings.HARD_KEYBOARD_SETTINGS
Add a shortcut (MOD+k) for convenience if the current keyboard is HID.
PR #4473 <https://github.com/Genymobile/scrcpy/pull/4473>
The audio output thread only reads samples from the buffer, and most of
the time, the audio receiver thread only writes samples to the buffer.
In these cases, using atomics avoids lock contention.
There are still corner cases where the audio receiver thread needs to
"read" samples (and drop them), so lock only in these cases.
PR #4572 <https://github.com/Genymobile/scrcpy/pull/4572>
If a line did not end with '\r', then the final `\n' was replaced by
'\0' for parsing the current line. This `\0` was then mistakenly
considered as the end of the whole "ip route" output, so the remaining
lines were not parsed, causing "scrcpy --tcpip" to fail in some cases.
To fix the issue, read the final character of the current line before it
is (possibly) overwritten by '\0'.
The slope encodes the drift between the device clock and the computer
clock. Its real value is expected very close to 1.
To estimate it, just assume it is exactly 1.
Since the clock is used to estimate very close points in the future, the
error caused by clock drift is totally negligible, and in practice it is
way lower than the slope estimation error.
Therefore, only estimate the offset.
If there is exactly one producer, then it can assume that the remaining
space in the buffer will only increase until it writes something.
This assumption may allow the producer to write to the buffer (up to a
known safe size) without any synchronization mechanism, thus allowing
to read and write different parts of the buffer in parallel.
The producer can then commit the write with a lock held, and update its
knowledge of the safe empty remaining space.
PR #3757 <https://github.com/Genymobile/scrcpy/pull/3757>
On click event, only the whole buttons state was passed to the device.
In addition, on ACTION_DOWN and ACTION_UP, pass the button associated to
the action.
Refs #3635 <https://github.com/Genymobile/scrcpy/issues/3635>
Co-authored-by: Romain Vimont <rom@rom1v.com>
Signed-off-by: Romain Vimont <rom@rom1v.com>
This util function was error-prone:
- it accepted a buffer as parameter (not necessarily a NUL-terminated
string) and its length (including the NUL char, if any);
- it wrote '\0' over the last character of the buffer, so the last
character was lost if the buffer was not a NUL-terminated string, and
even worse, it caused undefined behavior if the length was empty;
- it returned the length of the resulting NUL-terminated string,
which was inconsistent with the input buffer length.
In addition, it was not necessarily optimal:
- it wrote '\0' twice;
- it required to know the buffer length, that is the input string
length + 1, in advance.
Remove this function, and let the client use strcspn() manually.
The parser assumed that its input was a NUL-terminated string, but it
was not the case: it is just the raw output of "adb devices ip route".
In practice, it was harmless, since the output always ended with '\n'
(which was replaced by '\0' on truncation), but it was incorrect
nonetheless.
Always write a '\0' at the end of the buffer, and explicitly parse as a
NUL-terminated string. For that purpose, avoid the error-prone
sc_str_truncate() util function.
A scroll event might be produced when a mouse button is pressed (for
example when scrolling while selecting a text). For consistency, pass
the actual buttons state (instead of 0).
In practice, it seems that this use case does not work properly with
Android event injection, but it will work with HID mouse.