Extremely slow and crashing on Huawei Mate 10 Pro (EMUI 10.0)

[navid-zamani]

• I have read the FAQ.
• I have searched in existing issues.

Environment

• OS: Mint Linux
• scrcpy version: 16.0 & 12.1
• installation method: manual build with prebuilt server & apt
• device model: Huawei Mate 10 Pro
• Android version: 10 (= EMUI 10)

Describe the bug
Upon booting the phone, connecting USB, and starting scrcpy, the window content is black.
I then have to manually inject adb shell "input text $pin" to unlock.

After that the UI is extremely slow and laggy. The FPS counter mostly says 0 fps and every dozen lines or so, some number below 10 fps. Forcing a low resolution with -m 768 does not help. And it does not matter if I use version 12.1 or 16.0.

Worse, when I see the main screen of the phone, which takes 30s to 2 minutes there is a dialog at the bottom, to choose what type of USB connection I want (with only charging preselected). I click on “Cancel” and nothing happens. I wait 30s. Then when I I click on “Cancel” again, scrcpy(’s server?) crashes. With the window contents stuck. Closing scrcpy and restarting it results in that windows’s contents being black forever as far as I can tell. Right clicking onto in and waiting 30s does not help. Even twice with waiting 30s each time, or trice. Recording also gives a black screen.

To make things easier, I managed to enable “screen always on during charging” in the debug settings. Don’t ask me how. I must have gotten lucky. But back then, it already was so slow that it took some major timing and blind clicking skills to get to that menu option without waiting more than 30s and having the phone lock itself again.

I cannot verify what is happening on the phone itself, as the screen is broken. adb shell, file access via kdeconnect’s sshfs mount, and eves wifi logging in at my laptop’s hotspot works fine.

And most importantly: scrcpy works perfectly fine with my old Huawei ALE-L21.

I am sorry, I wish I could give more easily reproducible information. But I have no idea how to debug this one, as I cannot even fully tell when I actually get to see the phone screen’s contents and when it crashes.
If you tell me where to start debugging this, I may be able to do it myself, and give you better info.

Is it possible that scrcpy’s performance is dependent on the real physical screen hardware working? Is there a way to make scrcpy circumvent that, to test this hypothesis? (E.g. by making a virtual screen, defining that as the main one, and disabling the entire hardware one?)
Or is it due to Huawei’s AOSP fork (EMUI)?

Error output:

~$ scrcpy -m 768
INFO: scrcpy 1.16 <https://github.com/Genymobile/scrcpy>
* daemon not running; starting now at tcp:5037
* daemon started successfully
/usr/local/share/scrcpy/scrcpy-server: 1 file pushed. 2.8 MB/s (33622 bytes in 0.012s)
[server] INFO: Device: HUAWEI BLA-L29 (Android 10)
INFO: Renderer: opengl
INFO: OpenGL version: 3.0 Mesa 20.0.8
INFO: Trilinear filtering enabled
INFO: Initial texture: 384x768
[server] ERROR: Could not invoke method
java.lang.reflect.InvocationTargetException
        at java.lang.reflect.Method.invoke(Native Method)
        at com.genymobile.scrcpy.wrappers.InputManager.injectInputEvent(InputManager.java:36)
        at com.genymobile.scrcpy.Device.injectEvent(Device.java:169)
        at com.genymobile.scrcpy.Device.injectEvent(Device.java:173)
        at com.genymobile.scrcpy.Controller.injectTouch(Controller.java:211)
        at com.genymobile.scrcpy.Controller.handleEvent(Controller.java:94)
        at com.genymobile.scrcpy.Controller.control(Controller.java:71)
        at com.genymobile.scrcpy.Server$2.run(Server.java:89)
        at java.lang.Thread.run(Thread.java:929)
Caused by: android.os.DeadObjectException
        at android.os.BinderProxy.transactNative(Native Method)
        at android.os.BinderProxy.transact(BinderProxy.java:526)
        at android.hardware.input.IInputManager$Stub$Proxy.injectInputEvent(IInputManager.java:874)
        ... 9 more
[server] ERROR: Could not invoke method
java.lang.reflect.InvocationTargetException
        at java.lang.reflect.Method.invoke(Native Method)
        at com.genymobile.scrcpy.wrappers.InputManager.injectInputEvent(InputManager.java:36)
        at com.genymobile.scrcpy.Device.injectEvent(Device.java:169)
        at com.genymobile.scrcpy.Device.injectEvent(Device.java:173)
        at com.genymobile.scrcpy.Controller.injectTouch(Controller.java:211)
        at com.genymobile.scrcpy.Controller.handleEvent(Controller.java:94)
        at com.genymobile.scrcpy.Controller.control(Controller.java:71)
        at com.genymobile.scrcpy.Server$2.run(Server.java:89)
        at java.lang.Thread.run(Thread.java:929)
Caused by: android.os.DeadObjectException
        at android.os.BinderProxy.transactNative(Native Method)
        at android.os.BinderProxy.transact(BinderProxy.java:526)
        at android.hardware.input.IInputManager$Stub$Proxy.injectInputEvent(IInputManager.java:874)
        ... 9 more

[rom1v]

Is it possible that scrcpy’s performance is dependent on the real physical screen hardware working?

Yes: #1285 #1353 #1456

[navid-zamani]

OK, I solved it with pure luck!

1. Use --prefer-text!
2. Disable kdeconnectd on your PC!
3. Execute the adb shell "input text $pin"before starting scrcpy! Not during.

I don’t know which one of those it is, but now it works smoothly, as expected.
It might be the first one. As now, input doesn’t crash the thing anymore either. EMUI being weird like that fits with my general experience with it.