This change adds support for xdg_wm_base v6, which introduces
xdg_toplevel suspended state.
The suspended state is tied to the visibility of the window item so the
effects could possibily "resume" window content updates.
`Placements::placeSmart` searches for an optimal position for windows, attempting to minimize overlap. The core of this algorithm tracks the
client's height and width in `ch` and `cw`, which have been adjusted by -1. This simplifies logic determining the bottom and right points of a
window when you are starting at the top and left points.
However, this decision requires adjusting that number by +1 when doing the opposite: determining the top and left points when you start with
the bottom and right points.
placeSmart cycles through window locations, searching for acceptable nooks and crannies to fit a window in, nicely. It begins by checking
for places to put the top left corner of the window which abut another constraint. If that fails, it then tries to place the bottom right
abutting a constraining feature.
After finding a suitable bottom (or right) location, the top (or left) location must be determined, requiring the -1 adjustment to be undone.
This patch adds that +1 back in.
# The bug it solves
This error can be seen by opening a bunch of windows that are placed using the "Minimal Overlapping" rule. The open space on the screen will be tiled from left to right, and then top to bottom in the windows. Once no more windows can be placed like that, the next window will be placed at the extreme bottom-right corner. However, it will be one pixel too low and one pixel too far to the right---if you try to move the window, it will "snap" to the correct spot.
This single pixel may seem minor or even irrelevant, but when you use the "Present Windows" desktop effect on a multiple-monitor setup, this one pixel will cause the window to show up on both monitors.
Otherwise we will still react on a frameGeometryChanged signal
and try to relayout the popup when its transient parent was
already set to null leading to a crash.
BUG: 472532
There is a chance that DrmGpu::pageFlipHandler gets executed on the main
thread while drmModeAtomicCommit hasn't returned yet on the commit thread.
When this situation happens, the destructor of DrmAtomicCommit doesn't set
the buffers to be current for the relevant drm planes, and once it gets
deleted, the framebuffers get destroyed and the output turns off.
To prevent that from happening, this commit moves the relevant code to a
method that gets explicitly called from the pageflip handler.
In v5, the xdg_toplevel.wm_capabilities event had been introduced which
specifies a list of actions allowed by the compositors. Mainly useful to
client-side decorated apps.
Use the linear filter to ensure that the cursor doesn't look blocky with
some scale factors and use the clamp-to-edge wrap mode to avoid
potential artifacts when the image is scaled.
This reverts commit fd04fe04c0.
This change wasn't technically wrong, but presents an awkward developer
API until the point where we can port *all* PlasmaComponents to their
upstream QQC2 versions, and as such, it was premature.
Basically:
- PlasmaExtras.Heading -> Kirigami.Heading
- PlasmaComponents3.Label -> QQC2.label
We can do this because these components only existed in the past to use
special Plasma colors, but no visual styling. And the color stuff is
obsolete because Kirigami colors work correctly in Plasma now.
Everything was tested with a dark Plasma theme and a light color scheme
to ensure no regressions.
At the moment, the SurfaceItem needs to track individual properties that
may contribute to the buffer source box. That's error prone.
To fix that, this change makes the SurfaceInterface indicate when the
source box has changed and the SurfaceItem should sync its source box,
discard quads, etc.
Pending buffers for drm planes and crtcs are no longer tracked in the planes
and crtcs themselves, but instead in a DrmCommit object that is used as
the user data for the pageflip handler. This way multiple commits can be
pending at the same time without causing conflicts, and the handling of
pending buffers is simplified as well.
With color management, the main framebuffer has values over 1. As the effect used GL_RGBA8 for its
fbos, all values in them got clamped to 1, making the result look much darker than it should be. To
fix that, this commit changes it to use the same format as the main framebuffer, ensuring that the
range of values that can be stored is the same
This separate thread submits commits as late as possible, so that until
immediately before vblank the cursor position can still be updated, reducing
its latency and opening the door for more optimizations.
Vscode starts with a valid source rect but it resets it eventually by
calling wp_viewport.set_source(-1, -1, -1, -1).
On the other hand, `current.viewport.sourceGeometryIsSet` would be true
if that happens.
SurfaceInterface::bufferSourceBox() should use the buffer size when the
source rect has been unset otherwise the damage handling code will be
confused and it's likely that the scene won't issue repaint requests.
At the moment, graphics buffers coming from wayland and internal windows
use different code paths to update textures. However, they don't have
to.
If the internal windows are ported to GraphicsBuffer, it will be
possible to unify SurfacePixmapInternal and SurfacePixmapWayland to make
pixmap logic a bit simpler.
The buffer source box is synchronized when the surface-to-buffer matrix
changes. However, when using 100% scaling, it's likely that the
surface-to-buffer matrix will be identity and therefore no corresponding
signal to indicate the change will be emitted.
To fix that, we need to update the buffer source box also when the
buffer size changes.
