https://bugs.kde.org/show_bug.cgi?id=521079
Zamundaaa <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REPORTED |RESOLVED Resolution|--- |INTENTIONAL CC| |[email protected] --- Comment #4 from Zamundaaa <[email protected]> --- Direct scanout isn't a thing you can expect to kick in unconditionally. Compositing can be required because of anything from color profiles, HDR, night light, software brightness to driver or hardware restrictions. One of the restrictions with tearing specifically is that hardware cursor + direct scanout can't work atm, since the kernel rejects updating the cursor image or position while tearing is happening. If none of the obvious things prevent direct scanout, we can look into why it's not happening, but most likely it's normal. FTR with your GPU, the color related restrictions should be taken care of in Plasma 6.7. (In reply to randomland from comment #1) > If I enable tearing for vkcube using Window Settings from Alt + F3 menu, it > runs at a higher framerate and very clearly tears however the compositing > indicator still stays on screen. Is this expected behaviour? Yes. Direct scanout and tearing are unrelated to each other. (In reply to Marco Martin from comment #2) > Compositing being off is a thing only on an x11 session, there is just the > vsync being disabled so kwin will push frames as fast as it can instead of > trying to match exactly the screen refresh rate "compositing" and "compositing" are confusingly used with different meanings in different contexts. In the context of X11, "compositing" usually refers to an X11 compositor running and doing compositing for Xorg. In the context of Wayland, "compositing" usually refers to the compositor rendering with the GPU, as opposed to letting the scanout hardware take care of things. -- You are receiving this mail because: You are watching all bug changes.
