The KEY_FRAME_RATE parameter value is necessary for the configuration of
the encoder, but its actual value does not impact the frame rate (only
resources used by the encoder).
Therefore, it's an internal detail and should not be exposed by the
ScreenEncoder class.
Send client version as first parameter and check it at server start.
Signed-off-by: Yu-Chen Lin <npes87184@gmail.com>
Signed-off-by: Romain Vimont <rom@rom1v.com>
Some devices internally create a Handler when creating an input Surface,
causing an exception:
> Surface: java.lang.RuntimeException: Can't create handler inside
> thread that has not called Looper.prepare()
As a workaround, call Looper.prepareMainLooper() beforehand.
Fixes:
- <https://github.com/Genymobile/scrcpy/issues/240>
- <https://github.com/Genymobile/scrcpy/issues/921>
Signed-off-by: Romain Vimont <rom@rom1v.com>
Some devices do not have some methods that we invoke via reflection, or
their call do not return the expected value. In that case, do not crash
the whole controller.
Enable the attribute "console" of custom_target() introduced in meson
0.48. This allows to get a feedback of what gradle does (which can takes
a very long time).
This produces warnings because we declare to support meson >= 0.37, but
we don't want to stop supporting older versions for that. Older versions
just ignore the option:
> WARNING: Unknown keyword arguments in target scrcpy-server: console
Newer meson versions use it, but warn because we declare supporting
older versions:
> WARNING: Project targetting '>= 0.37' but tried to use feature
> introduced in '0.48.0': console arg in custom_target
Meson does not support conditional branches to suppress such warnings,
so just keep the warnings.
Add two shortcuts:
- Ctrl+o to turn the device screen off while mirroring
- Ctrl+Shift+o to turn it back on
On power on (either via the POWER key or BACK while screen is off), both
the device screen and the mirror are turned on.
<https://github.com/Genymobile/scrcpy/issues/175>
After the recent refactorings, a "control event" is not necessarily an
"event" (it may be a "command"). Similarly, the unique "device event"
used to send the device clipboard content is more a "reponse" to the
request from the client than an "event".
Rename both to "message", and rename the message types to better
describe their intent.
It was already possible to _paste_ (with Ctrl+v) the content of the
computer clipboard on the device. Technically, it injects a sequence of
events to generate the text.
Add a new feature (Ctrl+Shift+v) to copy to the device clipboard
instead, without injecting the content. Contrary to events injection,
this preserves the UTF-8 content exactly, so the text is not broken by
special characters.
<https://github.com/Genymobile/scrcpy/issues/413>
Parsing a String from a serialized control event, encoded as length (2
bytes) + data, will be necessary in several events.
Extract it to a separate method.
On Ctrl+C:
- the client sends a GET_CLIPBOARD command to the device;
- the device retrieve its current clipboard text and sends it in a
GET_CLIPBOARD device event;
- the client sets this text as the system clipboard text, so that it
can be pasted in another application.
Fixes <https://github.com/Genymobile/scrcpy/issues/145>
The socket used the device-to-computer direction to stream the video and
the computer-to-device direction to send control events.
Some features, like copy-paste from device to computer, require to send
non-video data from the device to the computer.
To make them possible, use two sockets:
- one for streaming the video from the device to the client;
- one for control/events in both directions.
Several commands were grouped under the same event type "command", with
a separate field to indicate the actual command.
Move these commands at the same level as other control events. It will
allow to implement commands with arguments.
If we don't do this trick, the prebuilt_server will be
../server/[the_user_defined_path]. In general, we will not give an relative path
based on build directory, which leads to wrong prebuilt_server path.
The building error:
ninja: error: '../scrcpy-server-v1.7.jar', needed by
'server/scrcpy-server.jar', missing and no known rule to make it
Signed-off-by: Yu-Chen Lin <npes87184@gmail.com>
Commit fefb9816a9 modified mouse events
serialization. The server-side parsing was updated to correctly read the
position, but the expected size of these events was not updated.
As a result, the server might try to parse incomplete events, leading
to BufferUnderflowException.
Fixes
<https://github.com/Genymobile/scrcpy/issues/350#issuecomment-456298816>.
To clean up the device, the client executed "adb shell rm" once the
server was guaranteed to be started (after the connection succeeded).
This implied to track whether the installation state, and failed if an
additional tunnel was used in "forward" mode:
<https://github.com/Genymobile/scrcpy/issues/386#issuecomment-453936034>
Instead, make the server unlink itself on start.
Mouse events position were unsigned (so negative values could not be
handled properly).
To avoid issues with negative values, mouse events outside the device
screen were ignored (commit a7fe9ad779).
But as a consequence, drag&drop were "broken" if the "drop" occurred
outside the device screen.
Instead, use signed 32-bits to store the position, and forward events
outside the device screen.
Fixes <https://github.com/Genymobile/scrcpy/issues/357>.
The client passes parameters to the server via "adb shell" arguments.
Use "-" instead of "" when no crop is specified to avoid empty
arguments, which are not handled the same way on all devices.
Fixed <https://github.com/Genymobile/scrcpy/issues/337>.
Configuration packets produced by MediaCodec have no valid PTS, and do
not produce frame. Do not queue their (invalid) PTS not to break the
matching between frames and their PTS.
Since PTS handling has been fixed, the recorder do not associate a PTS
to a wrong frame anymore, so PTS of "configuration packets" (which never
produce a frame), are never read by the recorder. Therefore, there is no
need to ignore them explicitly, so we can remove the MediaCodec flags
completely.
In "adb forward" mode, close the server socket as soon as the client is
connected.
Even if unlikely to be useful, it allows to run several instances of
scrcpy also in "adb forward" mode.
"adb reverse" currently does not work over tcpip (i.e. on a device
connected by "adb connect"):
<https://issuetracker.google.com/issues/37066218>
To work around the problem, if the call to "adb reverse" fails, then
fallback to "adb forward", and reverse the client/server roles.
Keep the "adb reverse" mode as the default because it does not involve
connection retries: when using "adb forward", the client must try to
connect successively until the server listens.
Due to the tunnel, every connect() will succeed, so the client must
attempt to read() to detect a connection failure. For this purpose, when
using the "adb forward" mode, the server initially writes a dummy byte,
read by the client.
Fixes <https://github.com/Genymobile/scrcpy/issues/5>.
