Android 14 beta lock orientation doesn't work as expected when the device goes into landscape mode.

[ssalenik]

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

Environment

• OS: macOS
• scrcpy version: 2.0
• installation method: brew
• device model: Pixel 7,
• Android version: Android 14 Beta (UpsideDownCake)

Describe the bug
Android 14 beta lock orientation doesn't work as expected when the device goes into landscape mode.
eg: if you launch: scrcpy --lock-video-orientation=0 then go into landscape in an app, you get this:

Looks like it no longer rotates the display output to fit the surface of the codec, but instead it keeps it in its orientation and scales it. Not clear if its a "bug" which will be fixed in the release, but seems possibly unlikely since its already in beta.

[vikingden8]

me too, I think this is a problem on new Android 14

[ssalenik]

OK, so now that the 14 source is released, I think the issue is due to this change in the SurfaceControl.setDisplayProjection fn:
Android 13: https://android.googlesource.com/platform/frameworks/base.git/+/refs/heads/android13-dev/core/java/android/view/SurfaceControl.java#2355

Android 14: https://android.googlesource.com/platform/frameworks/base.git/+/refs/tags/android-14.0.0_r2/core/java/android/view/SurfaceControl.java#2331

This fn now ignores the orientation param:

/**
--
  | * Because this API is now going through {@link DisplayManager}, orientation and displayRect
  | * will automatically be computed based on configuration changes. Because of this, the params
  | * orientation and displayRect are ignored
  | *
  | * @hide
  | */
  ```

[rom1v]

@ssalenik Thank you 👍

Reported here.

[ssalenik]

Thanks. I think it may be possible to find a work around by re-implementing this public static VirtualDisplay createVirtualDisplay fn here:
https://android.googlesource.com/platform/frameworks/base.git/+/refs/tags/android-14.0.0_r2/core/java/android/hardware/display/DisplayManager.java#1567

which is what is called by SurfaceControl.createDisplay fn here:
https://android.googlesource.com/platform/frameworks/base.git/+/refs/tags/android-14.0.0_r2/core/java/android/view/SurfaceControl.java#2385

And possibly adding this hidden display flag VIRTUAL_DISPLAY_FLAG_ROTATES_WITH_CONTENT: https://android.googlesource.com/platform/frameworks/base.git/+/refs/tags/android-14.0.0_r2/core/java/android/hardware/display/DisplayManager.java#372

To the VirtualDisplayConfig here:
https://android.googlesource.com/platform/frameworks/base.git/+/refs/tags/android-14.0.0_r2/core/java/android/hardware/display/DisplayManager.java#1577

I've used this hidden flag before with the MediaProjection api to accomplish the same thing.

[ssalenik]

FYI, I tried doing what I suggested above, but it didn't work.
I was able to re-implement the public static VirtualDisplay createVirtualDisplay fn in DisplayManager and add passing the VIRTUAL_DISPLAY_FLAG_ROTATES_WITH_CONTENT flag to the VirtualDisplayConfig, but it did not change the behaviour.

[ssalenik]

@rom1v fyi, in my own code I was able to create a work around for this by manually rotating the surface myself.
This requires to create a 2nd "intermediate" surface which the display writes to, then using opengl code to rotate it before outputting to the encoder surface.
I used this fairly old but still working google grafika library to help me do it so I didn't really have to write any opengl code., specifically the Sprite2d to do the rotation:
https://github.com/google/grafika/blob/master/app/src/main/java/com/android/grafika/gles/Sprite2d.java

[rom1v]

This requires to create a 2nd "intermediate" surface which the display writes to, then using opengl code to rotate it before outputting to the encoder surface.

@ssalenik Do you have a public branch which does this?

[ssalenik]

No, unfortunately that code is not open source. But I'll see if maybe I can make a patch, or at least write out the concept better with the scrcpy code.

[rom1v]

But I'll see if maybe I can make a patch, or at least write out the concept better with the scrcpy code.

@ssalenik Indeed, a base branch in the scrcpy codebase would help a lot 😉 Setting a surface from a SurfaceTexture to capture the display, executing a simple hardcoded shader (using a simple swizzle to just swap the color channels for example) and encoding the result to produce the video stream would be absolutely perfect (without additional libraries) 😎

Otherwise, I'll probably investigate in the future (at first glance, this sample should help).

[eiyooooo]

It seems that the "virtualDisplay" created by this method (introduced in Android 14)

scrcpy/server/src/main/java/com/genymobile/scrcpy/ScreenCapture.java

Lines 54 to 55 in 206809a

	virtualDisplay = ServiceManager.getDisplayManager()
	.createVirtualDisplay("scrcpy", videoRect.width(), videoRect.height(), device.getDisplayId(), surface);

can rotate by

scrcpy/server/src/main/java/com/genymobile/scrcpy/wrappers/WindowManager.java

Lines 104 to 120 in 206809a

	public void freezeRotation(int displayId, int rotation) {
	try {
	try {
	Method method = getFreezeDisplayRotationMethod();
	method.invoke(manager, displayId, rotation);
	} catch (ReflectiveOperationException e) {
	if (displayId == 0) {
	Method method = getFreezeRotationMethod();
	method.invoke(manager, rotation);
	} else {
	Ln.e("Could not invoke method", e);
	}
	}
	} catch (ReflectiveOperationException e) {
	Ln.e("Could not invoke method", e);
	}
	}

I don't have any device running Android 14, so it's hard for me to test.

You can try to rotate the "virtualDisplay" for this issue, it might be a solution.

Not this issue, seeing #4840

[gassion]

I have also encountered this problem, is there any good solution to solve it now? Thank you very much. @ssalenik