If effects->grabKeyboard() fails and effects->ungrabKeyboard() is called
later, kwin will crash due to an assert in the ungrabKeyboard() function.
This matters only on X11.
Right now it's just a helper to mark items as being affected by some effect,
to prevent direct scanout of the relevant item without needing to block direct
scanout for the whole screen
Rendering intents describe how to handle mapping between different colorspaces,
what to do with out of gamut values and what to do if the whitepoint doesn't match.
This way, clients can choose which behavior their content should get.
This effect is used to implement the visual bell accessibility feature.
It allows to implement it on Wayland and significantly improve it on X11,
where it's currently rather broken.
It offers two modes:
- Inverting the colors (code is based off the invert effect)
- Flashing a solid color
This ensures that different content on the screen matches with the user configured
reference / SDR luminance, and both simplifies SDR<->HDR mapping by removing the need
for special casing that situation and significantly improves the mapping in some cases.
As we don't get any reference luminance values for HDR content (yet), this commit
assumes that HDR content is prepared for the reference luminance of the preferred
color description.
The mastering display colorimetry describes what part of the colorspace
is actually used, which is important when we're sending desired metadata
about a screen using the rec.2020 container colorspace, or when the client
uses an "infinite" / extended colorspace like scRGB
As per the docs:
Note: This function does not need to be, and must not be, called when
using the software adaptation of Qt Quick.
This sets up RHI on the render control, which in turn sets RHI on the
window, which shouldn't exist when using software rendering.
BUG: 482663
BUG: 486078
Fullscreen effects typically will show all the windows, when the effect
ends having the windows disappear doesn't really work.
From a user point of view any full screen effect is a new task, we want
to cancel any preivous task.
BUG: 487299
When a new mouse event is made it updates the global position of that
device. This causes issues if a mouse event is forwarded with an
adjusted position then used afterwards.
`QPointingDevice::primaryPointingDevice` creates a new pointer device
internally if the seat name does not exist. It is then shared between
future usages.
BUG: 480864
The cube effect has a placeholder which can update the delegate at
runtime. There's an "add desktop" button which then might give us 3
virtual desktops. As a general rule any setter exposed via a declarative
API should always perform the setting.
Reloading has to be delayed because otherwise we unload the caller.
BUG: 486839
If the metadata of the effect is invalid, loadEffect will complain
rather than failing silently, making debugging issues a bit harder and
it's something that we are already checking for and shouldn't
realistically be happening.
Integrate with colorpicker effect to disable window darkening while
color picker effect is active. Unfortunately, this solution has couple
of limitations:
- active state of effects is not an observable property, so a new
property had to be added to the effects singleton;
- consequently, list of active effects is not an observable property, so
the whole thing could not be implemented in pure QML in the dialog
parent effects;
- actual isActive() state of the color picker for whatever reason
required that m_scheduledPosition is not an invalid point,
effectively making it always inactive except for a brief moment
between addRepaintFull() call and paintScreen() callback. That check
had to be removed.
- QColorDialog windows are still modal and darkened by default;
- QColorDialog on X11 does not use portals/KWin, so this trick does not
apply at all;
- effects->isScreenLocked() which isActive() depends on is not an
observable property either.
BUG: 172921
If they're rendered in prePaintScreen, the time needed to render them is not
accounted for in compositing scheduling, which may make KWin miss vblank
CCBUG: 482861
CCBUG: 452119
CCBUG: 482034
QuickEffect::setDelegate is exposed QML API.
The lifespan of assigned objects is therefore managed by the QML engine,
and we should be watching for deletion not actually deleting it.
Now that we have Wayland around, there's a whole branch of dependencies
that shouldn't be necessary anymore.
This allows to build KWin without all of it, allowing us to have a much
more compact alignment for cases where all the legacy software isn't
necessary anymore.
Bundle KWindowSystem X11-specific headers into it too, since it's part
of the same process.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
The overview and the zoom effect repaint the whole screen every frame.
But the problem is that there are cases when there's nothing to repaint.
I'm not quite sure why it happens. Maybe overview and other effects
should honor the repaint region, but on the other hand, they don't need
to because of the fullscreen effect api promises.
This change forces overview and zoom effect to use "generic paint" code
path in the workspace scene to force infiniteRegion() repaint regions.
BUG: 481523
NETWM forces a weird X11 dependency on KWin that doesn't necessarily
match what we want to do. Instead we decouple such a central class in
KWin like it's Window from KWindowSystem X11 support.
Signed-off-by: Falko Becker <falko.becker@mbition.io>
Overview and Grid modes have shortcuts assigned to them. While they
provide a way to toggle the overview effect between on and off state, in
other words overview <-> off or grid <-> off, it's not possible to move
between the modes by pressing those shortcuts, e.g. off -> overview ->
grid -> overview -> grid -> ... -> off.
The culprit seems to be that EffectTogglableState has two "inactive"
states - Inactive and Stopped. It's counter-intuitive and needs a further
cleanup.
To make switching between overview modes work, this change makes
EffectTogglableState::toggle() toggle the state based on the Active state.
There's only one active state.
CCBUG: 481335
Views are owned by the C++ backend, but also retrievable by invokables
to get neighbouring screens from JS space. By default Qt then transfers
ownership of the view to the QML collector. This results in double
ownership.
BUG: 480788
It can be used to simplify state tracking in some effects. The
restriction exists because there used to be separation between normal
and closed windows (Toplevel and Deleted), and one could reference
only Deleted windows. So it was easier just to forbid referencing still
alive windows.
This is because the Overview will activate itself at the end of a 1:1 gesture,
and a toggle action might actually deactivate it rather than activate it.
It seems like QWindow::setGeometry() won't update the associated output
if no platform window has been created, which is the case when running
overview or any other qml effect.
It's not clear whether this is a Qt bug or intended behavior.
qwindow.cpp contains comments assuming that the window is on the primary
output if no platform window exists.
QQuickWindow::effectiveDevicePixelRatio() uses the device pixel ratio
of the attached QQuickRenderTarget. Instead, the scale factor of the
output should be used, which is what QWindow::devicePixelRatio() returns.
Drops the doneCurrent as it was preventing proper cleanUp
because no context was current when textures were deleted.
Also avoid manipulating the context when Qt has the current
one, as various Qt classes have guards around their cleanup
handlers which rely on a current Qt context.
Despite the comment the order of render control and view destruction
needs to be switched as the QQuickWindow destructor calls into
the render control to notify if of window destruction.
BUG:478770
BUG:479846
FIXED-IN:6.0
