The purpose of handle_shortcut() was to group all actions together,
whether they are initiated from a text input event or a keycode event.
However, it did not handle the case where it was initiated from a mouse
event (a right-click must turn the screen on), since the action was
identified by the shortcut char.
Instead, expose one function per action, to be called directly from
where the event is handled.
The right-click is almost useless on Android, so use it to turn the
screen on.
Add a new control event type (command) to request the server to turn the
screen on.
The server is built as an APK to simplify the build, but in fact this is
a simple jar (it is not even signed).
In order to avoid confusion, rename it to .jar, so that users do not try
to "adb install" it.
Also rename it from "scrcpy" to "scrcpy-server" to distinguish from the
client-side.
The server path may be customized using SCRCPY_APK. If its basename is
different from "scrcpy.apk", it will be pushed with a different name,
so the execution would fail.
Therefore, force the push target filename.
On rotation, scrcpy resize the window to match the new rotation.
However, in fullscreen mode, setting the window size does not change the
windowed size on X11, so the behavior is incorrect.
To avoid the problem, apply the resize only after fullscreen is
disabled.
For readability, indent "case" in switch blocks.
Replace:
switch (x) {
case 1:
// ...
case 2:
// ...
case 3: { // a local scope block
int i = 42;
// ...
}
}
By:
switch (x) {
case 1:
// ...
case 2:
// ...
case 3: { // a local scope block
int i = 42;
// ...
}
}
Replace screenrecord execution by manual screen encoding using the
MediaCodec API.
The "screenrecord" solution had several drawbacks:
- screenrecord output is buffered, so tiny frames may not be accessible
immediately;
- it did not output a frame until the surface changed, leading to a
black screen on start;
- it is limited to 3 minutes recording, so it needed to be restarted;
- screenrecord added black borders in the video when the requested
dimensions did not preserve aspect-ratio exactly (sometimes
unavoidable since video dimensions must be multiple of 8);
- rotation handling was hacky (killing the process and starting a new
one).
Handling the encoding manually allows to solve all these problems.
Accept a parameter to limit the video size.
For instance, with "-m 960", the great side of the video will be scaled
down to 960 (if necessary), while the other side will be scaled down so
that the aspect ratio is preserved. Both dimensions must be a multiple
of 8, so black bands might be added, and the mouse positions must be
computed accordingly.
The video screen size on the client may differ from the real device
screen size (e.g. the video stream may be scaled down). As a
consequence, mouse events must be scaled to match the real device
coordinates.
For this purpose, make the client send the video screen size along with
the absolute pointer location, and the server scale the location to
match the real device size before injecting mouse events.
Currently, we only use screen information (width, height, rotation)
once at initialization, to send the device size to the client.
To be able to scale mouse events, make it accessible in memory. For this
purpose, replace the "static" DeviceUtil to a singleton Device, and
update it on every screen rotation.
Ctrl, Alt, Shift and Meta should not be transmitted to the Android
device: they may generate unwanted events. For instance, resizing the
window using Alt+click will generate an Alt event which may open a menu
on the device.
All keycodes that generate a text input must also be excluded, to avoid
the text input to be written twice.
