To allow seamless copy-paste, on Ctrl+v, a SET_CLIPBOARD request is
performed before injecting Ctrl+v.
But when HID keyboard is enabled, the Ctrl+v injection is not sent on
the same channel as the clipboard request, so they are not serialized,
and may occur in any order. If Ctrl+v happens to be injected before the
new clipboard content is set, then the old content is pasted instead,
which is incorrect.
To minimize the probability of occurrence of the wrong order, a delay of
2 milliseconds was added before injecting Ctrl+v. Then 5ms. But even
with 5ms, the wrong behavior sometimes happens.
To handle it properly, add an acknowledgement mechanism, so that Ctrl+v
is injected over AOA only after the SET_CLIPBOARD request has been
performed and acknowledged by the server.
Refs e4163321f0
Refs 45b0f8123a
PR #2814 <https://github.com/Genymobile/scrcpy/pull/2814>
Pass the information that device clipboard has been set to the key
processor. This avoids the keyprocessor to "guess", and paves the way to
implement a proper acknowledgement mechanism.
PR #2814 <https://github.com/Genymobile/scrcpy/pull/2814>
Mouse motion events were forwarded as soon as any mouse button was
pressed.
Instead, only consider left-click (and also middle-click and right-click
if --forward-all-clicks is enabled).
The input manager was partially initialized statically, but a call to
input_manager_init() was needed anyway, so initialize all the fields
from the "constructor".
This is consistent with the initialization of the other structs.
Double-click on extra mouse button to open the settings panel (a
single-click opens the notification panel).
This is consistent with the keyboard shortcut MOD+n+n.
PR #2264 <https://github.com/Genymobile/scrcpy/pull/2264>
Signed-off-by: Romain Vimont <rom@rom1v.com>
The collapsing action collapses any panels.
By the way, the Android method is named collapsePanels().
PR #2260 <https://github.com/Genymobile/scrcpy/pull/2260>
Signed-off-by: Romain Vimont <rom@rom1v.com>
The shortcut "back on screen on" is a bit special: the control is
requested by the client, but the actual event injection (POWER or BACK)
is determined on the device.
To properly inject DOWN and UP events for BACK, transmit the action as
a control parameter.
If the screen is off:
- on DOWN, inject POWER (DOWN and UP) (wake up the device immediately)
- on UP, do nothing
If the screen is on:
- on DOWN, inject BACK DOWN
- on UP, inject BACK UP
A corner case is when the screen turns off between the DOWN and UP
event. In that case, a BACK UP event will be injected, so it's harmless.
As a consequence of this change, the BACK button is now handled by
Android on mouse released. This is consistent with the keyboard shortcut
(Mod+b) behavior.
PR #2259 <https://github.com/Genymobile/scrcpy/pull/2259>
Refs #2258 <https://github.com/Genymobile/scrcpy/pull/2258>
The functions SDL_malloc(), SDL_free() and SDL_strdup() were used only
because strdup() was not available everywhere.
Now that it is available, use the native version of these functions.
A new "repeat" field has been added by
3c1ed5d86c, but it was not initialized in
every code path.
As a consequence, keycodes generated by shortcuts were sent with an
undetermined value, breaking some shortcuts (especially HOME) randomly.
Fixes#1643 <https://github.com/Genymobile/scrcpy/issues/1643>
Send COPY and CUT on MOD+c and MOD+x (only supported for Android >= 7).
The shortcuts Ctrl+c and Ctrl+x should generally also work (even before
Android 7), but the active Android app may use them for other actions
instead.
Pressing Ctrl+v on the device will typically paste the clipboard
content.
Before sending the key event, synchronize the computer clipboard to the
device clipboard to allow seamless copy-paste.
Pressing Alt+c generates a text event containing "c", so "c" was sent to
the device when --prefer-text was enabled.
Ignore text events when the mod state matches a shortcut modifier.
Remove the Cmd modifier on macOS, which was possible only for some
shortcuts but not all.
This paves the way to make the shortcut modifier customizable.
Touch events were HiDPI-scaled twice:
- once because the position (provided as floats between 0 and 1) were
converted in pixels using the drawable size (not the window size)
- once due to screen_convert_to_frame_coords()
One possible fix could be to compute the position in pixels from the
window size instead, but this would unnecessarily round the event
position to the nearest window coordinates (instead of drawable
coordinates).
Instead, expose two separate functions to convert to frame coordinates
from either window or drawable coordinates.
Fixes#1536 <https://github.com/Genymobile/scrcpy/issues/1536>
Refs #15 <https://github.com/Genymobile/scrcpy/issues/15>
Refs e40532a376
This reverts commit 8c8649cfcd.
I cannot reproduce the issue with Ctrl+Shift+o on any device, so in
practice it works, it's too bad to remove the feature for a random bug
on some Android versions on some devices.
Position and scale the content "manually" instead of relying on the
renderer "logical size".
This avoids possible rounding differences between the computed window
size and the content size, causing one row or column of black pixels on
the bottom or on the right.
This also avoids HiDPI scale issues, by computing the scaling manually.
This will also enable to draw items at their expected size on the screen
(unscaled).
Fixes#15 <https://github.com/Genymobile/scrcpy/issues/15>
Move the window-to-frame coordinates conversion from the input manager
to the screen.
This will allow to apply more screen-related transformations without
impacting the input manager.
Some compilers warns on uninitialized value in impossible case:
warning: variable 'result' is used uninitialized whenever switch
default is taken [-Wsometimes-uninitialized]
