What's "default orientation" and "current orientation"?

(In reply to Vlad Zahorodnii from comment #1)
> What's "default orientation" and "current orientation"?

thanks for the prompt reply

the default orientation would be auto rotation off, and no rotation applied. current rotation in this context would be any rotation that is not the "default orientation". for context, I have a chuwi Hi10x 2 in 1, the display is naturally a "portait" orientation, however when docked which is my typical use case. it is in landscape, the landscape is the "current orientation"

using SDL libmpv example for testing I have verified that gnome has working auto rotation, Sway and weston work for the "current orientation" when the app is launched, but sway does not support auto rotate, and I havent figured out how to rotate weston live so no testing was done there.  as for KDE, I have manually tried setting the video= panel_orientation= kernel flag as well as the rotate flag and neither have worked to remedy the situation

we don't support auto rotation when launching fullscreen apps, or am I misunderstanding it?

(In reply to Vlad Zahorodnii from comment #3)
> we don't support auto rotation when launching fullscreen apps, or am I
> misunderstanding it?

the issue is broadly, that the applications tested are forced into the "default orientation" regardless of manually changing rotation, or auto rotate

fullscreen mpv looks fine on a rotated output on my machine. Can you share some photos showing the problem (there's still a chance that I misunderstand the issue)? also, please run mpv with WAYLAND_DEBUG=1 and post the output here

Created attachment 157164 [details]
example of application in windowed mode

(In reply to Vlad Zahorodnii from comment #5)
> fullscreen mpv looks fine on a rotated output on my machine. Can you share
> some photos showing the problem (there's still a chance that I misunderstand
> the issue)? also, please run mpv with WAYLAND_DEBUG=1 and post the output
> here

I wasn't using mpv itself but rather this https://github.com/mpv-player/mpv-examples/blob/master/libmpv/sdl/main.c with a patch that adds SDL_SetWindowFullscreen(windows, 1)

I was also able to replicate the issue using supertux and supertuxkart. regardless here are the pictures of supertux

Created attachment 157165 [details]
example of fullscreen

Created attachment 157166 [details]
Ignore the last one, I accidentally uploaded the same image

Another thing to test: try setting KWIN_DRM_NO_DIRECT_SCANOUT=1 environment variable

Created attachment 157167 [details]
WAYLAND_DEBUG logs

Sorry for the delay, it took a minute to find an app that would actually spit the logs since most apps were running xwayland.

KWIN_DRM_NO_DIRECT_SCANOUT=1 did not help. there was no difference.

I went back and tested X11 directly, the issue only effects wayland, x11 seems to work just fine. When I reported the issue to SDL https://github.com/libsdl-org/SDL/issues/7439 this is what was pondered 

"... SDL reports the display orientation received from the compositor to the application, as well as adjusts the display coordinates for rotated displays. Beyond that, I'm not sure what else it is supposed to do to 'respect the compositor orientation'?"

I am facing this issue on a OneXPlayer, small laptop-like device, running an Intel 1165g7 and a tablet-screen that defaults to portrait orientation. What seems funny to me is that any kind of fullscreen app triggers the bug, e.g. YouTube fullscreen mode is sufficient. However, forcing an overlay, like changing volume, rotates the screen correctly, at least until the overlay disappears again which causes the screen to fall back to the incorrect orientiation.

Additionally, using YouTube for testing has shown that the device seems to confuse the orientation and rendering area. The "fullscreen" video is in fact squeezed into a part of the screen due to the incorrect rotation - but I am able to move the mouse outside of the video frame, giving me the impression that somewhere along the rendering, the surface to display the fullscreen content is incorrectly rotated.

Is there any log or other info I can provide to help solve this? I am running Plasma 5.27.4, Framework 5.105, Qt 5.15.9 and Linux 6.2.11.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/3995

Git commit 8ca38fb328606f8a0bababea2e07b36fd775768f by Xaver Hugl.
Committed on 21/04/2023 at 15:35.
Pushed by zamundaaa into branch 'master'.

backends/drm: fix buffer orientation check for direct scanout

Without hardware rotation, the buffer transform with always be "normal",
so all "normal" client buffers would be accepted for direct scanout, which
is not correct.

M  +1    -30   src/backends/drm/drm_egl_layer.cpp

https://invent.kde.org/plasma/kwin/commit/8ca38fb328606f8a0bababea2e07b36fd775768f

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/4002

Git commit 5e0349cd99be7c8728f93ba7cf0e2cf590756971 by Vlad Zahorodnii, on behalf of Xaver Hugl.
Committed on 21/04/2023 at 19:14.
Pushed by vladz into branch 'Plasma/5.27'.

backends/drm: fix buffer orientation check for direct scanout

Without hardware rotation, the buffer transform with always be "normal",
so all "normal" client buffers would be accepted for direct scanout, which
is not correct.

(cherry picked from commit 8ca38fb328606f8a0bababea2e07b36fd775768f)

M  +1    -30   src/backends/drm/drm_egl_layer.cpp

https://invent.kde.org/plasma/kwin/commit/5e0349cd99be7c8728f93ba7cf0e2cf590756971

tested and confirmed working!