Use UHID output reports to synchronize CapsLock and VerrNum states.
Co-authored-by: Romain Vimont <rom@rom1v.com>
Signed-off-by: Romain Vimont <rom@rom1v.com>
There is a dependency cycle in the initialization order:
- keyboard depends on controller
- controller depends on acksync
- acksync depends on keyboard initialization
To break this cycle, bind the async instance to the controller in a
second step.
Rename {keyboard,mouse}_inject to {keyboard,mouse}_sdk.
All implementations "inject" key events and mouse events, what differs
is the mechanism. For these implementations, the Android SDK API is used
to inject events.
Note that the input mode enum variants were already renamed
(SC_KEYBOARD_INPUT_MODE_SDK and SC_MOUSE_INPUT_MODE_SDK).
An event contained several fields:
- the accessory id
- the HID event data
- a field ack_to_wait specific to the AOA implementation.
Extract the HID event part to prepare the factorization of HID event
creation.
Until now, there was two modes for keyboard and mouse:
- event injection using the Android system API (default)
- HID/AOA over USB
For this reason, the options were exposed as simple flags:
- -K or --hid-keyboard to enable physical keyboard simulation (AOA)
- -M or --hid-mouse to enable physical mouse simulation (AOA)
Replace them by explicit --keyboard and --mouse options, with 3 possible
values:
- disabled
- sdk (default)
- aoa
This will allow to add a new mode (uhid).
Co-authored-by: Romain Vimont <rom@rom1v.com>
Signed-off-by: Romain Vimont <rom@rom1v.com>
The input manager assumed that if a controller was present, then both a
key processor and a mouse processor were present.
Remove this assumption, to support disabling keyboard and mouse
separately. This prepares the introduction of new command line options
--keyboard and --mouse.
Some functions in input_manager.c only have access to a sub-object (for
example the controller). For consistency, always pass the whole
input manager instance.
This will allow to add assertions when keyboard and mouse could be
disabled separately.
The assumption that underflow and overbuffering are caused by jitter
(and that the delay between the producer and consumer will be caught up)
does not always hold.
For example, if the consumer does not consume at the expected rate (the
SDL callback is not called often enough, which is an audio output
issue), many samples will be dropped due to overbuffering, decreasing
the average buffering indefinitely.
Prevent the average buffering to become negative to limit the
consequences of an unexpected behavior.
PR #4572 <https://github.com/Genymobile/scrcpy/pull/4572>
The buffering level does not change continuously: it increases abruptly
when a packet is received, and decreases abruptly when an audio block is
consumed.
To estimate the buffering level, a rolling average is used.
To make the buffering more stable, increase the smoothness of this
rolling average. This decreases the risk of enabling audio compensation
due to an estimation error.
PR #4572 <https://github.com/Genymobile/scrcpy/pull/4572>
Use different thresholds for enabling and disabling compensation.
Concretely, enable compensation if the difference between the average
and the target buffering levels exceeds 4 ms (instead of 1 ms). This
avoids unnecessary compensation due to small noise in buffering level
estimation.
But keep a smaller threshold (1 ms) for disabling compensation, so that
the buffering level is restored closer to the target value. This avoids
to keep the actual level close to the compensation threshold.
PR #4572 <https://github.com/Genymobile/scrcpy/pull/4572>
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>
Some actions may be performed when scrcpy exits, currently:
- disable "show touches"
- restore "stay on while plugged in"
- power off screen
- restore "power mode" (to disable "turn screen off")
They are performed from a separate process so that they can be executed
even when scrcpy-server is killed (e.g. if the device is unplugged).
The clean up actions to perform were configured when scrcpy started.
Given that there is no method to read the current "power mode" in
Android, and that "turn screen off" can be applied at any time using an
scrcpy shortcut, there was no way to determine if "power mode" had to be
restored on exit. Therefore, it was always restored to "normal", even
when not necessary.
However, setting the "power mode" is quite fragile on some devices, and
may cause some issues, so it is preferable to call it only when
necessary (when "turn screen off" has actually been called).
For that purpose, make the scrcpy-server main process and the clean up
process communicate the actions to perform over a pipe (stdin/stdout),
so that they can be changed dynamically. In particular, when the power
mode is changed at runtime, notify the clean up process.
Refs 1beec99f82
Refs #4456 <https://github.com/Genymobile/scrcpy/issues/4456>
Refs #4624 <https://github.com/Genymobile/scrcpy/issues/4624>
PR #4649 <https://github.com/Genymobile/scrcpy/pull/4649>
This exception is a super-type of:
- ClassNotFoundException
- IllegalAccessException
- InstantiationException
- InvocationTargetException
- NoSuchFieldException
- NoSuchMethodException
Use it to simplify.
Create the service managers from each manager wrapper class rather than
from their getter in ServiceManager.
The way a wrapper retrieve the underlying service is an implementation
detail, and it must be consistent with the way it accesses it, so it is
better to write the creation in the wrapper.
Power on the device on start only if video capture is enabled.
Note that it only impacts display mirroring, since control is completely
disabled if video source is camera.
Refs 110b3a16f6
If the initial timestamp could not be retrieved, use the current time as
returned by System.nanoTime(). In practice, it is the same time base as
AudioRecord timestamps.
Fixes#4536 <https://github.com/Genymobile/scrcpy/issues/4536>
The result is assigned to a long (64-bit signed integer), but the
intermediate multiplication was stored in an int (32-bit signed
integer).
This value is only used as a fallback when no timestamp could be
retrieved, that's why it did not cause too much harm so far.
Fixes#4536 <https://github.com/Genymobile/scrcpy/issues/4536>
Reported by checkstyle:
> [ant:checkstyle] [INFO]
> scrcpy/server/src/main/java/com/genymobile/scrcpy/wrappers/ClipboardManager.java:48:
> Line is longer than 150 characters (found 167). [LineLength]
