Summary:
The GLX backend might need a combination of swap and composite timer events for
continous painting.
The reason for that is that if the buffer age extension is not available we
fall back to copies in case not the whole screen is repainted.
The timer logic is adapted to make this possible in a lean way what cleans up
the Compositor class in several ways.
Test Plan: Tested on X11 (with/without swap events, buffer age enabled) and Wayland.
Reviewers: #kwin
Subscribers: hurikhan77, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26216
Summary:
I could never reproduce the crash, but we know from gdb that it's from
the decorationSettings object
We are setting the same QObject instance as a context property in
multiple contexts at once. This is already slightly odd especially from the POV of
Qt's internal property cache.
Given we want one object to be exposed to all contexts, we can expose it
to the parent context only once and achieve the same result in a simpler
way.
BUG: 411166
Test Plan:
Verified opening and closing system settings still worked for me.
I could never reproduce the original crash.
Reviewers: #kwin, ngraham
Reviewed By: ngraham
Subscribers: ngraham, apol, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25913
Summary:
The buffer shape is in buffer-local coordinates and must be mapped to
window coordinates. After that, we are free to map it to the global screen
coordinates.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25733
Summary:
Activate intel swap events by default if available. They were hidden behind an
environmental variable because of some critical release blocking issue years
ago.
Manual testing indicates that there are no issues anymore with this extension.
Since it allows us to use swap events with MESA drivers for optimized repaints
enable swap events by default again.
For now leave a modified environment variable to switch back to using no swap
events easily.
CCBUG: 342582
Test Plan: i915
Reviewers: #kwin
Subscribers: zzag, broulik, kwin
Tags: #kwin
Maniphest Tasks: T11071
Differential Revision: https://phabricator.kde.org/D25300
Summary:
Add a small getter to query information internally if the backend supports
swap events. Defaults to true as it is the default in the GBM Wayland backend.
Test Plan: i915
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Maniphest Tasks: T11071
Differential Revision: https://phabricator.kde.org/D25298
When initializing a property we loop through the drmModeObjectProperties
object and search for the property by its name.
Once found we create the Property object and there should be not another one
with the same name afterwards. In any case we would leak memory. Therefore just
directly return once the property was found.
This gives us the added benefit that we can put out a warning in case the
property was not found in the loop, what should not happen with the properties
we use.
This is just a code cosmetic change to have the same values internally like the
kernel for the type enum. In the logic there should not be a difference since
the enum values are mapped at runtime.
Summary:
This cleans up some of the code, moves and deletes superfluous functions,
improves in-code docs and runtime warnings.
Test Plan: On vt.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25867
Summary:
According to Gl 3.2 (page 501) and 4.5 (page 204) specs the initial state of
the default framebuffer is already BACK. Therefore we do not need to set it
explicitly.
When we draw in the future to alternative framebuffers which do not have back
buffers this call is fatal.
Test Plan: No tearing on Wayland, tearing as before on X11.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25868
Summary:
This is a small overhaul of the EglGbmBackend. Functions are restructured,
white space added and variables renamed for better readability and style
aligned with Frameworks Coding Style.
Test Plan: Session starts.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25830
This reverts commit 9151bb7b9e.
This reverts commit ac4dce1c20.
This reverts commit 754b72d155.
In order to make the fix work, we need to redirect the client window
instead of the frame window. However, we cannot to do that because
Xwayland expects the toplevel window(in our case, the frame window)
to be redirected.
Another solution to the texture bleeding issue must be found.
CCBUG: 257566
CCBUG: 360549
Summary:
Quite long time ago, window decorations were painted on real X11 windows.
The nicest thing about that approach is that we get both contents of the
client and the frame window at the same time. However, somewhere around
KDE 4.2 - 4.3 times, decoration rendering architecture had been changed
to what we have now.
I've mentioned the previous decoration rendering design because it didn't
have a problem that the new design has, namely the texture bleeding issue.
In the name of better performance, opengl scene puts all decoration parts
to an atlas. This is totally reasonable, however we must be super cautious
about things such as the GL_LINEAR filter.
The GL_LINEAR filter may need to sample a couple of neighboring texels
in order to produce the final texel value. However, since all decoration
parts now live in a single texture, we have to make sure that we don't
sample texels that belong to another decoration part.
This patch fixes the texture bleeding problem by padding each individual
decoration part in the atlas. There is another solution for this problem
though. We could render a window into an offscreen texture and then map
that texture on the transformed window geometry. This would work well and
we definitely need an offscreen rendering path in the opengl scene,
however it's not feasible at the moment since we need to break the window
quads API. Also, it would be great to have as less as possible stuff going
on between invocation of Scene::Window::performPaint() and getting the
corresponding pixel data on the screen.
There is a good chance that the new padding stuff may make you vomit. If
it does so, I'm all ears for the suggestions how to make the code more
nicer.
BUG: 257566
BUG: 360549
CCBUG: 412573
FIXED-IN: 5.18.0
Reviewers: #kwin
Subscribers: fredrik, kwin, fvogt
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25611
Summary:
Since KDE 4.2 - 4.3 times, KWin doesn't paint window decorations on real
X11 windows, except when compositing is turned off. This leaves us with
a problem. The actual client contents is inside a larger texture with no
useful pixel data around it. This and decoration texture bleeding are
the main factors that contribute to 1px gap between the server-side
decoration and client contents with effects such as wobbly windows, and
zoom.
Another problem with naming frame pixmap instead of client pixmap is
that it doesn't quite go along with wayland. It only makes more difficult
to abstract window quad generation in the scene.
Since we don't actually need the frame window when compositing is on,
there is nothing that holds us from redirecting client windows instead
of frame windows. This will help us to fix the texture bleeding issue
and also help us with the ongoing redesign of the scene.
Test Plan: X11 clients are still composited.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25610
Summary:
Small intermediate refactor. For now just do the normal rotation when a flipped
transform is requested. In the future we might want to provide the possibility
to flip the output image.
Test Plan: Compiles
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25649
This backend absolutely does not make sense to use on anything
resembling a "desktop computer" as bshah explained to me. Still, I
somehow have the corresponding optional dependencies installed and
so I triggered the problem.
Reviewed-By: bshah
Summary:
Instead of using Qt::ScreenOrientation use an enum class that is directly
mapped to KWayland's transformation enums. This simplifies the code.
Test Plan: Compiles and transformations work as before.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Maniphest Tasks: T11670
Differential Revision: https://phabricator.kde.org/D25558
Summary:
Qt has its own thing where a type might also have corresponding list
alias, e.g. QObject and QObjectList, QWidget and QWidgetList. I don't
know why Qt does that, maybe for some historical reasons, but what
matters is that we copy this pattern here in KWin. While this pattern
might be useful with some long list types, for example
QList<QWeakPointer<TabBoxClient>> TabBoxClientList
in general, it causes more harm than good. For example, we've got two
new client types, do we need corresponding list typedefs for them? If
no, why do we have ClientList and so on?
Another problem with these typedefs is that you need to include utils.h
header in order to use them. A better way to handle such things is to
just forward declare a client class (if that's possible) and use it
directly with QList or QVector. This way translation units don't get
"bloated" with utils.h stuff for no apparent reason.
So, in order to make code more consistent and easier to follow, this
change drops some of our custom typedefs. Namely ConstClientList,
ClientList, DeletedList, UnmanagedList, ToplevelList, and GroupList.
Test Plan: Compiles.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24950
Summary:
KDE is known for having a strong view on the client-side decorations vs
server-side decorations issue. The main argument raised against CSD is
that desktop will look less consistent when clients start drawing window
decorations by themselves, which is somewhat true. It all ties to how
well each toolkit is integrated with the desktop environment.
KDE doesn't control the desktop market on Linux. Another big "player"
is GNOME. Both KDE and GNOME have very polarized views on in which
direction desktop should move forward. The KDE community is pushing more
toward server-side decorations while the GNOME community is pushing
more toward client-side decorations. Both communities have developed
great applications and it's not rare to see a GNOME application being
used in KDE Plasma. The only problem is that these different views are
not left behind the curtain and our users pay the price. Resizing GTK
clients in Plasma became practically impossible due to resize borders
having small hit area.
When a client draws its window decoration, it's more likely that it also
draws the drop-shadow around the decoration. The compositor must know
the extents of the shadow so things like snapping and so on work as
expected. And here lies the problem... While the xdg-shell protocol has
a way to specify such things, the NetWM spec doesn't have anything like
that. There's _GTK_FRAME_EXTENTS in the wild, however the problem with
it is that it's a proprietary atom, which is specific only to GTK apps.
Due to that, _GTK_FRAME_EXTENTS wasn't implemented because implementing
anything like that would require major changes in how we think about
geometry.
Recent xdg-shell window geometry patches adjusted geometry abstractions
in kwin to such a degree that it's very easy to add support for client
side decorated clients on X11. We just have to make sure that the
X11Client class provides correct buffer geometry and frame geometry when
the gtk frame extents are set.
Even though the X11 code is feature frozen, I still think it's worth
to have _GTK_FRAME_EXTENTS support in kwin because it will fix the resize
issues. Also, because KWin/Wayland is unfortunately far from becoming
default, it will help us with testing some implementation bits of the
window geometry from xdg-shell.
BUG: 390550
FIXED-IN: 5.18.0
Test Plan:
Things like quick tiling, maximizing, tiling scripts and so on work as
expected with GTK clients.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: cblack, trmdi, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24660
Summary:
Currently our Scene is quite naive about geometry. It assumes that the
window frame wraps the attached buffer/client. While this is true for X11
clients, such geometry model is not suitable for client-side decorated
clients, in our case for xdg-shell clients that set window geometry
other than the bounding rectangle of the main surface.
In general, the proposed solution doesn't make any concrete assumptions
about the order between frame and buffer geometry, however we may still
need to reconsider the design of Scene once it starts to generate quads
for sub-surfaces.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, romangg, kwin
Tags: #kwin
Maniphest Tasks: T10867
Differential Revision: https://phabricator.kde.org/D24462
Summary:
In case of a failed atomic commit the previous mode should be fallen back to.
For orientation provide again a setter that DRM backend can use to set the
transform back to the last working one.
Test Plan: Compiles, fallback works, cursor still messed up somewhat (scaling issue?).
Reviewers: #kwin
Subscribers: zzag, kwin
Tags: #kwin
Maniphest Tasks: T11670
Differential Revision: https://phabricator.kde.org/D25507
Summary:
We use internally Qt:ScreenOrientation for representing output transforms.
This is not ideal since the values do not map directly to Wayland transform
values, but we can make it work by using OR combinations of
Qt:ScreenOrientations.
Do this for now and see if we should not better introduce an internal enum
mapped directly.
Additionally the OR combinations need to be handled in the drm backend at
various places accordingly as well (see TODOs).
Test Plan: Compiles
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Maniphest Tasks: T11670
Differential Revision: https://phabricator.kde.org/D25505
Summary:
Move the Wayland output device and output transform calls from DRM backend
to AbstractWaylandOutput. This leaves still some loose ends that need to be
tied up later. On failed commit we want to fall back to last working state
and orientation getter in general needs some more refactoring.
Test Plan: Compiles.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Maniphest Tasks: T11670
Differential Revision: https://phabricator.kde.org/D25504
I build kwindowsystem with -DEXCLUDE_DEPRECATED_BEFORE_AND_AT=5.62.0,
and this broke here. Use the exact same condition as the one around
those virtual methods in the base class.
Same fix as https://phabricator.kde.org/D25488
Summary:
this makes the "no borders" option do something: however it cause many
other issues with many themes that weren't really designed for "no
borders"
it fixes the "tiny borders" for almost all themes, as the whole calculation before
was
completely wrong
Test Plan:
Some themes work way better now, some look broken with no border or no side borders
some look perfect with those options
another issue is that aurorae is going to support no borders, it has to support like
breeze resizing from the shadows
Reviewers: #plasma, #kwin, davidedmundson
Reviewed By: #plasma, #kwin, davidedmundson
Subscribers: davidedmundson, ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25146
Summary:
Effects::checkInputWindowEvent(QWheelEvent *e) existed but it was not
hooked up to anything and would never be called.
This patch adds the relevant handling in the wayland filter, X filter so
the existing method gets called.
EffectQuickView is updated to handle wheel events.
Test Plan:
Used a ListView via an EffectQuickView in an effect.
I can now scroll with the mouse.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25292
Summary:
Removes a tonne of complex code, means any future improvements to our
QtQuick integration only need to be in one place.
QML logic remains in Aurorae as it does complex things. All other
aurorae specialties remain.
Only functional difference is that we now use a shared GL context
between window frames, which Plasma::FrameSVG will make use of.
Test Plan:
kcmshell5 kwindecoration
ran some aurorrae themes on my kwin. Look the same as master
Reviewers: #kwin, mart
Reviewed By: mart
Subscribers: mart, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25206
Summary:
Compositing in X11 was done time shifted, meaning that we paint first, then
wait one vblank interval length and present on prepareRenderingFrame the
previous paint result. This is supposed to make sure we don't miss the vblank
and in case of block till retrace be able to continue issuing commands and
only shortly before next vblank present.
This is counter-intuitiv, not how we do it on Wayland or even on MESA with X.
The reason seems to be that the GLX backend was in the beginning written
against Nvidia proprietary driver which needed this but nowadays even this
driver defaults to non-blocking behavior on buffer swap.
Therefore remove this legacy anomaly fully and directly present after paint.
We then wait one refresh cycle and in the future can optimize this by delaying
the paint and present till shortly before vsync.
Test Plan: kwin_x11 tested on i915 and Nvidia proprietary driver.
Reviewers: #kwin
Subscribers: zzag, alexeymin, kwin
Tags: #kwin
Maniphest Tasks: T11071
Differential Revision: https://phabricator.kde.org/D23514
Summary:
Selecting not to vsync does not make sense for an X11 compositor. In the end
we want clients to be able to present async if they want to but the compositor
is supposed to send swaps with vsync to the XServer in order to not generate
tearing artifacts.
There was also a detection logic which did some questionable things in case
vsync was not available. I don't think this is necessary at all since we can
just always run a timer to present with or without vsync.
Test Plan: kwin_x11 tested on i915.
Reviewers: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Maniphest Tasks: T11071
Differential Revision: https://phabricator.kde.org/D23511
Summary:
Current hardware should suppport either GLX_EXT_swap_control or
GLX_MESA_swap_control. To simplify code remove the usage of SGI extensions.
Test Plan: kwin_x11 tested on i915.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: davidedmundson, kwin
Tags: #kwin
Maniphest Tasks: T11071
Differential Revision: https://phabricator.kde.org/D23510
Summary:
It is not clear what the advantage of triple buffering is for KWin. An X11
compositor is meant to swap buffers once every monitor cycle. For that triple
buffering is not necessary.
The functionality is not maintained, does not reliably work as displayed by
the existence of an environment variable to force some behavior, pollutes
our code and every compositing-related problem that might be mitigated with
triple buffering should find a simpler and more fitting solution with other
means.
There is one caveat which is if we shall block for retrace. We set it
currently according to the result of the swap profiler and in the most common
case with double buffering it is set to true. But on Nvidia systems this might
be actual the wrong behavior. Instead of trying to work around this ignore
the issue for now and move the overall architecture to something less complex
by presenting after paint how we do it in the Wayland DRM backend and with
double buffering on GLX (although this is at the moment also borken because
we actually present then twice).
Test Plan: kwin_x11 tested on i915.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, fredrik, kwin
Tags: #kwin
Maniphest Tasks: T11071
Differential Revision: https://phabricator.kde.org/D23504
Summary:
We support the stable xdg-shell protocol nowadays. So use this one instead of
version 6 unstable.
Test Plan:
Runs with other recent patches in KWin nested. In Weston nested session still
not yet working.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25129
Summary:
Per protocol a zero-size can be sent indicating that the client should resize
its surface to its liking. For now change the code such that it at least sends
the ack-configure back and leaves the current size untouched.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25128
Summary:
After setting the xdg-surface role an initial commit must be sent per
protocol description.
This fixes Wayland nested session after commit 84de8d135d made this
requirement explicit.
Test Plan: Launched Wayland nested session.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25127
Summary:
With recent Mesa updates (19.2.1), MESA_EGL_NO_X11_HEADERS doesn't have
any effect. So, let's include fixx11h.h instead.
Test Plan: I am able to build kwin once again.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24840
