-
-
Notifications
You must be signed in to change notification settings - Fork 10.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add --hid-capture & --hid-replay options #4556
base: dev
Are you sure you want to change the base?
Conversation
This also moves the `sc_hid_event` type to a separate file, to enable the other classes to use it without requiring the several other object files to be linked.
@rom1v Note: I have tested it extensively on Linux, but I haven't tried cross-compiling to Windows yet. I'll check whether it can compile successfully on Windows after your code review. |
@rom1v The branch currently has merge conflicts due to changes in the past two months. Before I rebase, I'd like to ask whether you have unsubmitted feedback or any other blockers to merging the PR. |
First of all, thank you for your PR. It's a lot of work, with a lot attention to details (as per your PR description) ❤️ Sorry for the delay (the UHID feature took priority 😉). StreamingInitially, I did not consider the "live" recording/replay of events, so loading the whole file (which should be small) then replaying it would be ok. But I like the idea to support this use case 👍 ReplayDuring the replay, keyboard and mouse should be disabled (a mouse move during a replay breaks everything). For me, the most important use case for this feature is to enable USB debugging on a device with a broken screen (but other people might have other use cases). ThreadingTo minimize timing errors, the wait should be as close as possible as the input injection. So IMO, the thread waiting during The thread which parses the file might be a separate thread posting the parsed events in a queue along with their timings, as you said:
TBH, I think it might as well be the same thread, since the "injection" needs to wait for I/O to get the data anyway, so unless parsing takes a long time (in which case pipelining could improve the progress), I'm not sure it could make a difference. But why not. FormatI think a binary format would be simpler. Parsing text in C is a PITA. I already parse some text because I have no choice in What do you think? And I'm not sure there is an important need to edit HID event data manually in text. What I have in mind is something like:
(the size of the HID event might be deduced from the device) I think we should add a protocol version at the beginning of the file, to be able to make changes later but still be able to replay old recorded files. Also, a minor detail: the timestamps should start at 0 in the recorded file. AOA/UHIDWhen you implemented the PR, HID was only supported via AOA. Now there is UHID. Your contribution is great! I'm sorry that the codebase changed a lot since your PR was written (causing conflicts). Also, I'm aware that changing from a text format to a binary format is quite a big change, but the binary version should be simpler (I'd really prefer not to maintain more code which parses text in C when this is not absolutely necessary). Thank you again 😉 |
how this work please please ? I absolutely need it please |
Because this PR has not been merged you would have to check out the branch locally and compile the code yourself. Or you could wait until I found time to update the patch to implement the changes requested by the maintainer of this project. |
I have an issue using the functionality and cannot get this to work. I recorded some mouse activity with
and then tried to replay.
This is the log file created with the tool. Any ideas what might cause the issue? |
This PR introduces the
--hid-record
and--hid-replay
flags to support the use case of capturing events and replaying it (#4468). I have designed it such that it can also replay from a stream, currently through a fifo pipe to support the use case of targeting multiple devices at once (#4179). FIFO pipes are UNIX only, but the implementation is easily extensible to support streaming over a local socket (e.g. TCP, which would also work on Windows).Documentation and unit tests are included.
Tested as follows:
[timestamp] [accessory id] [hex-encoded space-separated event data]
. This simple format is chosen to make it easier to edit the event data manually if desired. Blank lines and lines with#
are ignored, everything else is rejected.meson setup x --buildtype=debug --strip -Db_lto=true -Dprebuilt_server=/usr/share/scrcpy/scrcpy-server -Db_sanitize=address,undefined && ninja -Cx
A note on the design: