Scrcpy interaction with OPPO Phone is not working

[EloZ27]

I have tried scrcpy and various guidelines for mirroring phones via scrcpy but it seems that the interaction with keyboard and mouse and audio does not work with my OPPO F11.

Help

[Britford]

In case this helps troubleshoot the display size issues: tl;dr scrcpy cuts off part of the screen instead of scaling it. 1200x1920 gets cut down to 1080x1900. -m 1700 fixes it.

My Lenovo tablet has a 1920x1200 screen. scrcpy outputs 1920x1080 and the other 120 pixels are just cut off. In portrait mode, the right side of the screen is cut off. In landscape, the bottom of the screen is missing. Touch events do not work.

scrcpy -m 1920 # does not help scrcpy -m 1700 # seems to work, entire screen is displayed, touch works I don't know the exact point, but values over 1700 work, less than 1700 or so do not. 1700 seems like an odd value to fix the issue. Maybe the anomaly will help diagnose the root cause.

scrcpy scrcpy 1.24 https://github.com/Genymobile/scrcpy scrcpy-server: 1 file pushed, 0 skipped. 145.9 MB/s (41159 bytes in 0.000s) [server] INFO: Device: LENOVO Lenovo TB-X606F (Android 10) INFO: Renderer: direct3d INFO: Initial texture: 1200x1920 INFO: New texture: 1080x1920 [server] WARN: Ignore touch event, it was generated for a different device size

[hhhaiai]

i have same case.

scrcpy 1.24 <https://github.com/Genymobile/scrcpy>
/opt/local/share/scrcpy/scrcpy-server:...ped. 46.3 MB/s (41159 bytes in 0.001s)
[server] INFO: Device: OPPO PACM00 (Android 10)
2024-03-15 16:30:17.679 scrcpy[9815:243314] INFO: Renderer: metal
2024-03-15 16:30:17.686 scrcpy[9815:243314] ERROR: Could not open image codec: /opt/local/share/icons/hicolor/256x256/apps/scrcpy.png
2024-03-15 16:30:17.686 scrcpy[9815:243314] WARN: Could not load icon
2024-03-15 16:30:17.686 scrcpy[9815:243314] INFO: Initial texture: 1080x2280
2024-03-15 16:30:18.087 scrcpy[9815:243314] INFO: New texture: 910x1920
[server] WARN: Ignore touch event, it was generated for a different device size
[server] WARN: Ignore touch event, it was generated for a different device size
[server] WARN: Ignore touch event, it was generated for a different device size
[server] WARN: Ignore touch event, it was generated for a different device size

[rom1v]

@hhhaiai see #1645.

[rom1v]

@hhhaiai And also:

scrcpy 1.24

Ultra-old. You should upgrade to the latest version.

[hhhaiai]

@hhhaiai And also:

scrcpy 1.24

Ultra-old. You should upgrade to the latest version.

ok

[hhhaiai]

@hhhaiai see #1645.

3Q

[hhhaiai]

@rom1v same case.

scrcpy --prefer-text
scrcpy 2.4 <https://github.com/Genymobile/scrcpy>
INFO: ADB device found:
INFO:     -->   (usb)  PVRKKRAAV8IBININ                device  PACM00
/usr/local/Cellar/scrcpy/2.4/share/scrcpy/scrcpy-server: 1 file pushed, 0 skipped. 246.9 MB/s (69007 bytes in 0.000s)
[server] INFO: Device: [OPPO] OPPO PACM00 (Android 10)
[server] WARN: Audio disabled: it is not supported before Android 11
INFO: Renderer: metal
WARN: Demuxer 'audio': stream explicitly disabled by the device
INFO: Texture: 1080x2280
INFO: Texture: 910x1920

[server] WARN: Ignore touch event, it was generated for a different device size
[server] WARN: Ignore touch event, it was generated for a different device size
[server] WARN: Ignore touch event, it was generated for a different device size
[server] WARN: Ignore touch event, it was generated for a different device size
[server] WARN: Ignore touch event, it was generated for a different device size
[server] WARN: Ignore touch event, it was generated for a different device size
[server] WARN: Ignore touch event, it was generated for a different device size
[server] WARN: Ignore touch event, it was generated for a different device size
[server] WARN: Ignore touch event, it was generated for a different device size
[server] WARN: Ignore touch event, it was generated for a different device size

[hhhaiai]

@hhhaiai And also:

scrcpy 1.24

Ultra-old. You should upgrade to the latest version.

already update 2.4, still has same exception

[rom1v]

@hhhaiai #1645

scrcpy -m1920

[hhhaiai]

scrcpy -m1920

It's ok。 why not auto support general size.

3Q~~

[hhhaiai]

@hhhaiai #1645

scrcpy -m1920

very 3Q. this play is OK . "scrcpy -m1920" ,the oppo phone size "INFO: Texture: 912x1920"

check size and update

[rom1v]

why not auto support general size.

Because this is a bug in the encoder: we request a size, it produces a video with a different size without notice (and we can't know that easily on the device side without parsing the encoded video stream).

In general, scrcpy tries a size, then attempts a smaller size if it fails… But some encoders don't fail, but decide to produce a video with a different size instead.

[hhhaiai]

why not auto support general size.

Because this is a bug in the encoder: we request a size, it produces a video with a different size without notice (and we can't know that easily on the device side without parsing the encoded video stream).

In general, scrcpy tries a size, then attempts a smaller size if it fails… But some encoders don't fail, but decide to produce a video with a different size instead.

First startup, will prompt [INFO: Texture: 910x1920] Should we first detect the resolution before the decoder starts working, that is, adjust the default parameters based on the second 1920, and then start the encoder

• logs

scrcpy 2.4 <https://github.com/Genymobile/scrcpy>
INFO: ADB device found:
INFO:     -->   (usb)  PVRKKRAAV8IBININ                device  PACM00
/usr/local/Cellar/scrcpy/2.4/share/scrcpy/scrcpy-server: 1 file pushed, 0 skipped. 68.0 MB/s (69007 bytes in 0.001s)
[server] INFO: Device: [OPPO] OPPO PACM00 (Android 10)
[server] WARN: Audio disabled: it is not supported before Android 11
INFO: Renderer: metal
WARN: Demuxer 'audio': stream explicitly disabled by the device
INFO: Texture: 1080x2280
INFO: Texture: 910x1920

[rom1v]

The actual resolution is detected on the client side, once the video stream is parsed/decoded.

The server side thinks the resolution is what it requested.

When then client sends a mouse events, the server detects a mismatch (which can happen in expected conditions like when the device is physically rotated between the instant an event is triggered on the client side and the time it is injected on the server side), and ignores the event (with a warning).

[hhhaiai]

The actual resolution is detected on the client side, once the video stream is parsed/decoded.

The server side thinks the resolution is what it requested.

When then client sends a mouse events, the server detects a mismatch (which can happen in expected conditions like when the device is physically rotated between the instant an event is triggered on the client side and the time it is injected on the server side), and ignores the event (with a warning).

How is this solution (scrcpy - m1920 *) implemented? When the user types the scrcpy command, they do not directly start the operation. Instead, they first check the resolution and obtain the truly operable resolution (INFO: Texture: 910x1920). At this time, they work according to the implementation of the scheme (scrcpy - m1920 ). Equivalent to, after default detection, we input different resolutions to different devices, and scrcpy is approximately equal to the dynamic parsing resolution, and then execute scrcpy - m1920

[rom1v]

Instead, they first check the resolution and obtain the truly operable resolution

That's a lot of work / round trip / guess to workaround an encoder bug which impacts only few devices.

Btw, in some cases -m1920 does not fix the problem, because many encoders require both dimensions to be a multiple of 8 (for example see https://github.com/Genymobile/scrcpy/issues/1645#issuecomment-1326684192). And you would have to handle this encoder bug on rotation too (the encoder might accept the initial size, but after a rotation the width or height exceeds its maximum and sends a video with another size). Anyway, a good solution would be to make the encoder fail if it does not support the requested size, but that's up to the encoders implementations.

Btw, you could try with another encoder.

[hhhaiai]

Instead, they first check the resolution and obtain the truly operable resolution

That's a lot of work / round trip / guess to workaround an encoder bug which impacts only few devices.

Btw, in some cases -m1920 does not fix the problem, because many encoders require both dimensions to be a multiple of 8 (for example see #1645 (comment)). And you would have to handle this encoder bug on rotation too (the encoder might accept the initial size, but after a rotation the width or height exceeds its maximum and sends a video with another size). Anyway, a good solution would be to make the encoder fail if it does not support the requested size, but that's up to the encoders implementations.

Btw, you could try with another encoder.

What you said is indeed an issue, and compatibility issues with a few devices are indeed a troublesome matter

Now is a compatibility issue with some devices. As time goes on, it is expected that the number of devices with this issue will continue to increase. It may not be - m1920 in the future, but may be devices with a resolution of -m3xxx or higher

Replace the encoder as per your proposal

$scrcpy -- list encoders
Scrcpy 2.4< https://github.com/Genymobile/scrcpy >
INFO: ADB device found:
INFO: -->(USB) PVRKRAAV8IBININ device PACM00
/Usr/local/Cellar/scrcpy/2.4/share/scrcpy/scrcpy server: 1 file pushed, 0 skipped 282.3 MB/s (69007 bytes in 0.000s)
[server] INFO: Device: [OPPO] OPPO PACM00 (Android 10)
[server] INFO: List of video encoders:
--Video code=h264-- video encoder='OMX MTK VIDEO ENCODER AVC '
--Video code=h264-- video encoder='c2. android. avc. encoder '
--Video code=h264-- video encoder='OMX. Google. h264. encoder '
[server] INFO: List of audio encoders:
--Audio code=opus -- audio encoder='c2. android. opus. encoder '
--Audio code=aac -- audio encoder='OMX. Google. aac. encoder '
--Audio code=aac -- audio encoder='c2. android. aac. encoder '
--Audio code=flac -- audio encoder='OMX. Google. flac. encoder '
--Audio code=flac -- audio encoder='c2. android. flac. encoder '

There are two decoders that can work. Can the decoders be dynamically switched during operation

#Success
--Video code=h264-- video encoder='c2. android. avc. encoder '
--Video code=h264-- video encoder='OMX. Google. h264. encoder '

Of course, this is also a suggestion Thank you from the bottom of my heart for your dedication. This excellent project is really amazing

[rom1v]

it is expected that the number of devices with this issue will continue to increase.

Why that? If the encoder does not support the requested size, it should fail (as most of encoders do).

Also, another problem is that the encoder produces a video at a different resolution than that requested, but we don't know how the video is scaled/cropped (some may add some black borders, other may stretch the video…), so we don't know for sure how to map input events back to thebdevice coordinates. Btw, in your case, one dimension is 910, which is not even a multiple of 8.

Can the decoders be dynamically switched during operation

No, one must be explicitly selected. There is no absolute criteria to select "the best".

[hhhaiai]

it is expected that the number of devices with this issue will continue to increase.

Why that? If the encoder does not support the requested size, it should fail (as most of encoders do).

Also, another problem is that the encoder produces a video at a different resolution than that requested, but we don't know how the video is scaled/cropped (some may add some black borders, other may stretch the video…), so we don't know for sure how to map input events back to thebdevice coordinates. Btw, in your case, one dimension is 910, which is not even a multiple of 8.

Can the decoders be dynamically switched during operation

No, one must be explicitly selected. There is no absolute criteria to select "the best".

ok. 3Q

[riotcult]

#1518 (comment)

But probably not related.

Oh in fact, that might be related: the client sends clicks for a window having dimensions different from the ones provided by the device.

If you remove these lines, it should "work" (it may click at a wrong location though):

https://github.com/Genymobile/scrcpy/blob/e99b896ae2b6a59d5f7f2b76a3dd9c29f4838013/server/src/main/java/com/genymobile/scrcpy/Device.java#L134-L138

INFO: Initial texture: 1080x2336
INFO: New texture: 888x1920

What if you run scrcpy -m1920? Do clicks work in that case?

Hey man I am new to all this can you guide me through all that I have to do for this to work?

[rom1v]

@riotcult Read https://github.com/Genymobile/scrcpy/blob/master/doc/windows.md#run Execute scrcpy -m1920.