Originally created by: BrutuZ
Environment
- OS: Windows 10
- scrcpy version: 2.3.1
- installation method: Windows x64 ZIP Release (scrcpy-win64-v2.3.1.zip)
- device model: Teclast T50 Pro ([server] INFO: Device: [Teclast] Teclast T50Pro_W_ROW (Android 13))
- Android version: 13
Describe the bug
After connecting to the device the screen is mirrored but slightly cropped and if I try to interact with it the console is flooded with [server] WARN: Ignore touch event, it was generated for a different device size.
scrcpy --tcpip=tablet.lan --window-title "Tablet"
scrcpy 2.3.1 <https://github.com/Genymobile/scrcpy>
INFO: Connecting to tablet.lan:5555...
INFO: Connected to tablet.lan:5555
.\scrcpy-server: 1 file pushed, 0 skipped. 39.0 MB/s (66007 bytes in 0.002s)
[server] INFO: Device: [Teclast] Teclast T50Pro_W_ROW (Android 13)
INFO: Renderer: direct3d
INFO: Texture: 1200x2000
INFO: Texture: 1080x1920
[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
WARN: Killing the server...
I found [#2190] [#4244] [#4509] and consequently the --max-size workaround from https://github.com/Genymobile/scrcpy/issues/1645#issuecomment-670433990, however it didn't work with the higher values (-m2000 nor -m1920) as the comment indicated, I can only suspect it has something to do with both Texture lines being equal as opposed to Initial Texture and New texture.
I went the roundabout route of writing a
adb connect tablet.lan
adb shell content insert --uri content://settings/system --bind name:s:user_rotation --bind value:i:0
adb shell wm size 1080x1920
scrcpy --pause-on-exit=if-error --tcpip=tablet.lan --window-title "Tablet" --turn-screen-off
adb shell content insert --uri content://settings/system --bind name:s:user_rotation --bind value:i:0
adb shell wm size 1200x2000
adb disconnect tablet.lan
that would change the WindowManager size with adb shell wm size 1080x1920 (thanks to [#4469]) before calling scrcpy and resetting it afterwards, which worked but threw the aspect ratio a little off on the device itself while connected.
Trough trial and error I eventually found a minimum threshold of -m1800 that works, but given how that isn't any of the 4 sizes reported I thought it was still worth mentioning in a new issue.
Originally posted by: rom1v
Thank you for your report.
The cause is still the same: the encoder does not report an error when requesting a size which it does not support (so scrcpy thinks it works), but internally it captures at a different size.
So in the end you must pass a
--max-sizeso that the requested size is a supported size.For example,
-m1920does not work, because it probably uses1152×1920, while the max supported size is1080×1920.