It's effectively unused and removing it allows us to get rid of
GLTexture field, which is very useful for abstracting the concept of a
"render target" across OpenGL and QPainter backends.
It's currently being used only by the X11 standalone backend. We should
either port the X11 backend to manual dirty state tracking or waiting
until it gets dropped. The main motivation for getting rid of the dirty
state tracking in the GLTexture is that it keeps kwin open for
alternative opengl wrappers, e.g. QOpenGL, and it simplifies GLTexture
code.
Because the GLRenderTarget and the GLVertexBuffer use the global
coordinate system, they are not ergonomic in render layers.
Assigning the device pixel ratio to GLRenderTarget and GLVertexBuffer is
an interesting api design choice too. Scaling is a window system
abstraction, which is absent in OpenGL or Vulkan. For example, it's not
possible to create an OpenGL texture with a scale factor of 2. It only
works with device pixels.
This change makes the GLRenderTarget and the GLVertexBuffer more
ergonomic for usages other than rendering the workspace by removing all
the global coordinate system and scaling stuff. That's the
responsibility of the users of those two classes.
In order to support layered rendering and tiled outputs KWin needs to be
able to split rendering of outputs into multiple surfaces. This commit
prepares the drm backend for that, by moving most of the code in EglGbmBackend
out to a EglGbmSurface class, which will later be used for overlay surfaces
and rendering to multiple connectors side by side.
In doing that, this commit also cleans up the code a bit, removes a lot of
now unnecessary multi-gpu stuff and potentially makes modesets a little
bit more efficient by re-using resources more often.
This allows to track per effect dependencies more precisely. The main
problem with a library and a comment next to it saying who needs it is
that the comment can get easily outdated.
There are two operations failing currently, so we QEXPECT_FAIL
them for now:
- A new client is not moved to the screen set by the rule
(Wayland only). Affects Apply, Force and Remember
- Disabling and enabling an output will not move the client
to the Forced screen (On X11 and Wayland, BUG:409979)
/proc/%/exec always points to the canonical/real path of a binary,
the exec field of a .desktop might contain a symlink and therefore
differ from canonical path.
Explicitely canonicalizing the path in exec prevents this mismatch.
The first move() in X11Client::createDecoration() will alter the client
size, which will result in the subsequent resize() incorrectly resizing
to a smaller window size.
In order to fix that issue, this change makes X11Client adjust the
frame geometry atomically after creating or destroying window decoration.
BUG: 449988
If the window is initially maximized, there won't be any current
decoration when XdgToplevelClient changes the maximize mode, we need to
use m_nextDecoration.
BUG: 450053
With the xdg_toplevel.configure_bounds event, the compositor will be
able to indicate the client the maximum desired surface size.
It can be used to prevent mapping too big application windows, etc.
We're setting this env variable because earlier we used it to force kwin to use its special QPA so we need to change that back to something sensible.
However setting it to Wayland breaks apps that ship their own Qt with missing or broken Wayland support.
Set it to be empty instead. Well-behaved Qt apps will use Wayland regardless because of XDG_SESSION_TYPE.
BUG: 450000
When a window leaves the current virtual desktop, we need to schedule a
workspace repaint so the compositor repaints the old region of the
window on the current desktop.
In hindsight, the scene graph must schedule a repaint, but it's not
doable with the current effects api, it will be changed with future
refactoring changes.
BUG: 444172
Otherwise we get the filename to the library and not the KPackage.
The plugin having this set is most likely a leftover, because KPackage plugins
to not need to define a library.
BUG: 449881
QPlatformScreen::virtualSiblings() must return a list of screens on the
virtual desktop, otherwise QToolTip will use
QGuiApplication::primaryScreen() instead of looking up the screen where
the decoration tooltip must be shown using QDesktopWidget::screenNumber().
BUG: 432860
recordFrame requires an openGL context. This is typically done after a
frame is rendered, but when we send a frame after a cursor move this is
not guaranteed.
BUG: 448162
Despite the argument naming, the input for WindowMotionManager::calculate is supposed to be a
delta, not an absolute time. Giving it a delta fixes the PresentWindows in the DesktopGrid.
BUG: 443971
The quads for the left and right window decorations were broken in
3b4d55837. The problem is only visible for window decorations with more
than one color.
Currently, if kwin_wayland crashes at shutdown, the launcher can
potentially spawn it again. This change addresses that issue by making
the wrapper ignore the QProcess::finished() signal.
Mixing of current and next state can create all sorts of undefined
behavior, e.g. windows not moving to the desired location or
experiencing issues when tiling a maximized window.
BUG: 449541
Currently, the Cursors::currentCursorChanged signal is wired to the
updateCursor() function which calls xcb_xfixes_hide_cursor() or
xcb_xfixes_show_cursor() depending if the cursor is hidden. However, the
currentCursorChanged signal can be emitted if the cursor changed, e.g. a
new pixmap attached, or its visibility status changes.
The zoom effect hides the pointer, but when user hovers ui elements, it
will most likely change and result in more than one xcb_xfixes_hide_cursor()
calls.
It appears like xcb_xfixes_hide_cursor() is implemented as a reference
counter, i.e. if xcb_xfixes_hide_cursor() is called two times, then you
must call xcb_xfixes_show_cursor() two times as well.
This change adds a dedicated signal to indicate whether the cursor is
hidden to avoid calling xcb_xfixes_hide_cursor() multiple times while
the screen is scaled.
BUG: 448537
With connection(), we will look up the x11 connection property on
kwinApp() object, which is less efficient than just calling a method on
the app object.
