-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
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
Sending keyboard events as physical keyboard instead of virtual keyboard #279
Comments
See #87 (comment) about OTG. |
Hello |
@rom1v what about letting computer dealing with input method and just pass input string to phone? |
Hi, @AlynxZhou Does the problem become to be able to input (Chinese) words from computer? If we pass the string to clipboard, there will be inconvenience to use. We need to paste again and again in phone. On the other hand, if we want to directly pass to input field. As I know, there are many restricts. For instance, how about webview? In my opinion, unless we can cover these problems. It is not an elegant solution yet. Thanks. |
Maybe there is a hope. |
This is what the client sends to the server (except for letters and space since v1.4, see #87). The problem is that the device does not support injecting characters other than ASCII. See handle text inputs.
See #87 (comment).
When you press AltGr+letter on your OTG keyboard, or on your computer? |
I press AltGr+letter on phisical keyboard and get correct diacritical letter on android. |
@lasek101 OK, so this comment totally applies: #87 (comment) This works because an OTG keyboard sends HID events over USB directly, which is not possible from a computer (except using HID over AOA). |
So, this is definitely not possible in scrcpy? |
Alternativly mayby it is possible to use phisical keyboard like virtual in a way that: when I long press letter 'a' I get option to choose what character I want to send i.e. 'ą'. |
@rom1v I think HID events is the best way however I know little about Android development and USB HID, if I know I can help... |
The problem is not how to generate the key, but how to inject it without root access into the system. See Handle accented characters.
It would be great, but it may be a bit complicated. Since you don't necessarily use a USB keyboard on your computer, you need to retrieve the key events via SDL, and "convert" them into raw USB HID events (is the mapping easy?). And you need to enable AOA (which does not work on all devices, and I don't know how to communicate over AOA from Windows). See discussion about audio forwarding: #14.
Generating HID events from SDL key events would be great 😉 |
I understand what we need, but I am questioning about whether we have a proper way to simulate a "virtual device" on Android without root... It seems AOA is not proper way for this? |
@AlynxZhou Yes, this is another alternative. It would require to install an APK though, so this may be "optional" (install the additional keyboard if you want to support "special characters"). |
Installed KDE Plasma and test failed: KDE Connect cannot forward Chinese character too... |
Is there a PoC for this? |
@amosbird No. |
Ok. I asked that after coming across this https://github.com/rom1v/aoa-hid-bug . Looking forward for a PoC :D |
Finished a dirty PoC. It works as expected. https://github.com/amosbird/scrcpy/blob/master/app/src/usb_hid_keys.h#L482 |
Cool, thank you for the PoC 👍 I had to add the diff --git a/app/meson.build b/app/meson.build
index 319548a..8b2456c 100644
--- a/app/meson.build
+++ b/app/meson.build
@@ -29,6 +29,7 @@ if not get_option('crossbuild_windows')
dependency('libavutil'),
dependency('sdl2'),
dependency('libusb-1.0'),
+ dependency('threads'),
]
else (and of course change my pid:vid) Currently, it does not handle special chars (e.g. if I press the key Could you link some HID doc/spec you used to generate these tables, please? https://github.com/amosbird/scrcpy/blob/master/app/src/usb_hid_keys.h#L27 Do you know how to use USB on Windows with libusb (and make AOA work on Windows, too)? |
yeah, that commit is broken. Now it works fine.
https://gist.github.com/MightyPork/6da26e382a7ad91b5496ee55fdc73db2
Sorry I have no idea. |
@rom1v hmm, the media control is very unreliable via |
Thanks. The AOSP doc is there: https://source.android.com/devices/input/keyboard-devices
Cool, text input are not interleaved anymore. However, I still can't press |
hmm, I'm not sure where that issue resides. Can you input |
I've iterated all the combinations of the 4 bytes HID data. None of them play/pause the music for me.... |
finally achieved media control. The HID interface is really dark. |
Another issue is HID mode depends on USB, so it also needs to check whether wireless is used... |
Good question :) |
Personally I prefer HID. And some related questions: If user choose HID explicitly, and HID set up failed, scrcpy should exit, that's OK, but if HID is default, user adds no options, and it failed, now should scrcpy quit, or fallback to inject automatically? |
Any ideas on this? Currently I am trying to make a Your advice is very important and I hope we can have an agreement on this soon so a PR can be made. |
Yes, you could do something like: --input-mode=auto # the default if not specified, which attempts to use HID then fallback
--input-mode=hid # force HID
--input-mode=inject # force injection (or a better name) |
I've already done this, and what's your opinion about the third choice's name? I'm not so familiar to it. |
I chose inject because the code just call it https://github.com/Genymobile/scrcpy/blob/master/app/src/input_manager.c#L90 |
Check AlynxZhou@c2f337b for the implementation |
In order to make (sorry, wrong url) HID keyboard is now more like a module, and makes the code clear. |
I currently feels OK for |
Another question - seems controller which send key events and mouse events to android is running on a controller thread, do we also need a thread for hid keyboard? |
I'd like to try this, however, it seems a lot of refactor is needed. |
Yes, I/O to send the HID events must not be done from the UI thread 👍 |
Working on this, I'll create another thread for AoA, like controller. |
Done via AlynxZhou@e4ca327 I decide not to update |
Implemented HID mouse today, however it works awful (HID mouse events only contains relative x and y change, so if you move cursor outside scrcpy's window, you lose cursor sync, and also an awful delay)(delay maybe is problem of my code, but still too hard to sync cursors). I've plugged my mouse into my Android phone, the only useful things is that I can use side buttons for forward and backward in chrome and select text in text entries. Because scrcpy's existing mouse experience is good enough so I won't submit my HID mouse code. I'll do some cleaning and send PR of HID keyboard soon. |
I wrote an article about the detailed logic of this PR in my blog, English version can be visit on https://sh.alynx.one/posts/Simulate-Physical-Keyboard-in-Scrcpy-via-USB-HID-over-AOAv2/#EnglishVersion. |
Isn't it possible to send absolute positions, by changing this line in the mouse report descriptor (hid1_11.pdf, Appendix E, §
to
Btw, in absolute mode, one byte might not be sufficient, so maybe (cf |
Yes, this should work, but I never try it, because most mice uses relative position, and another problem is what's the unit of absolute position? Pixels? Then different devices have different resolutions.
No problem, actually my own mouse uses 2 bytes for relative position. 1 byte is the minimal requirement. |
This provides a better input experience, by simulating a physical keyboard. It converts SDL keyboard events to proper HID events, and send them over AOAv2. This is a rewriting and bugfix of the origin code from @amosbird: <#279 (comment)> The feature is enabled the command line option -K or --keyboard-hid, and is only available on Linux, over USB. Refs <https://source.android.com/devices/accessories/aoa2#hid-support> Refs <https://www.usb.org/sites/default/files/hid1_11.pdf> Signed-off-by: Romain Vimont <rom@rom1v.com>
This provides a better input experience, by simulating a physical keyboard. It converts SDL keyboard events to proper HID events, and send them over AOAv2. This is a rewriting and bugfix of the origin code from @amosbird: <#279 (comment)> The feature is enabled the command line option -K or --keyboard-hid, and is only available on Linux, over USB. Refs <https://source.android.com/devices/accessories/aoa2#hid-support> Refs <https://www.usb.org/sites/default/files/hid1_11.pdf> Signed-off-by: Romain Vimont <rom@rom1v.com>
This provides a better input experience, by simulating a physical keyboard. It converts SDL keyboard events to proper HID events, and send them over AOAv2. This is a rewriting and bugfix of the origin code from @amosbird: <#279 (comment)> The feature is enabled the command line option -K or --keyboard-hid, and is only available on Linux, over USB. Refs <https://source.android.com/devices/accessories/aoa2#hid-support> Refs <https://www.usb.org/sites/default/files/hid1_11.pdf> Signed-off-by: Romain Vimont <rom@rom1v.com>
This provides a better input experience, by simulating a physical keyboard. It converts SDL keyboard events to proper HID events, and send them over AOAv2. This is a rewriting and bugfix of the origin code from @amosbird: <#279 (comment)> The feature is enabled the command line option -K or --keyboard-hid, and is only available on Linux, over USB. Refs <https://source.android.com/devices/accessories/aoa2#hid-support> Refs <https://www.usb.org/sites/default/files/hid1_11.pdf> PR #2632 <#2632> Signed-off-by: Romain Vimont <rom@rom1v.com>
This provides a better input experience, by simulating a physical keyboard. It converts SDL keyboard events to proper HID events, and send them over AOAv2. This is a rewriting and bugfix of the origin code from @amosbird: <#279 (comment)> The feature is enabled the command line option -K or --hid-keyboard, and is only available on Linux, over USB. Refs <https://source.android.com/devices/accessories/aoa2#hid-support> Refs <https://www.usb.org/sites/default/files/hid1_11.pdf> PR #2632 <#2632> Signed-off-by: Romain Vimont <rom@rom1v.com>
Closed by #2632. |
@rom1v can we use OTG mode on iphone as well? |
Current it send keyboard events as virtual keyboard (like input method keyboard), however google pinyin input supports physical keyboard with OTG to input, physical can use numbers to choose words which is really convenient and saves half of screen, if it can send as physical keyboard it will be better (because actually we are using a physical keyboard on computer).
The text was updated successfully, but these errors were encountered: