1. 17 Mar, 2020 1 commit
    • Aleix Pol Gonzalez's avatar
      Fix compiler warnings · cca0e15b
      Aleix Pol Gonzalez authored
      Summary: No need to keep them around for no reason.
      
      Test Plan: Tested the plugins I thought could be affected. Have been using it for a couple of days without problems
      
      Reviewers: #kwin, zzag
      
      Reviewed By: #kwin, zzag
      
      Subscribers: zzag, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D28062
      cca0e15b
  2. 16 Jan, 2020 7 commits
  3. 30 Dec, 2019 1 commit
    • Roman Gilg's avatar
      Flexible composite swap and timer events · 1e3128b0
      Roman Gilg authored
      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
      1e3128b0
  4. 12 Dec, 2019 2 commits
    • Roman Gilg's avatar
      [platforms/x11/standalone] Use intel swap events by default · e7da4d65
      Roman Gilg authored
      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
      e7da4d65
    • Roman Gilg's avatar
      Add hasSwapEvent getter · a55dee3b
      Roman Gilg authored
      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
      a55dee3b
  5. 27 Nov, 2019 1 commit
    • Vlad Zahorodnii's avatar
      [x11] Add support for _GTK_FRAME_EXTENTS · 84d75cb5
      Vlad Zahorodnii authored
      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
      84d75cb5
  6. 14 Nov, 2019 4 commits
    • Roman Gilg's avatar
      [platforms/x11] Never block on retrace, always present after paint · 8d137290
      Roman Gilg authored
      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
      8d137290
    • Roman Gilg's avatar
      Remove vsync detection and configurability · b3a19f9e
      Roman Gilg authored
      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
      b3a19f9e
    • Roman Gilg's avatar
      [platforms/x11/standalone] Remove SGI swap control and video sync · 285adc19
      Roman Gilg authored
      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
      285adc19
    • Roman Gilg's avatar
      [platforms/x11] Remove triple buffering detection · ad892ce3
      Roman Gilg authored
      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
      ad892ce3
  7. 15 Oct, 2019 1 commit
    • Fabian Vogt's avatar
      glx: Don't use sRGB configs on llvmpipe with depth 16 · 4982dfd5
      Fabian Vogt authored
      Summary:
      This is necessary to keep openQA working, which uses LLVMpipe as a
      renderer on a Cirrus device that operates in depth 16.
      
      LLVMpipe advertises 24/32 bit sRGB configurations on this setup, but
      they cannot be presented.
      
      CCBUG: 408594
      
      Test Plan: Compile tested only.
      
      Reviewers: fvogt, #kwin, zzag
      
      Reviewed By: fvogt, #kwin, zzag
      
      Subscribers: romangg, sbergeron, fvogt, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D22203
      4982dfd5
  8. 27 Sep, 2019 1 commit
    • David Edmundson's avatar
      [libkwineffects] Introduce API to easily show a QtQuick scene in an effect · 40b0296d
      David Edmundson authored
      Summary:
      EffectQuickView/Scene is a convenient class to render a QtQuick
      scenegraph into an effect.
      
      Current methods (such as present windows) involve creating an underlying
      platform window which is expensive, causes a headache to filter out
      again in the rest of the code, and only works as an overlay.
      
      The new class exposes things more natively to an effect where we don't
      mess with real windows, we can perform the painting anywhere in the view
      and we don't have issues with hiding/closing.
      
      QtQuick has both software and hardware accelerated modes, and kwin also
      has 3 render backends. Every combination is supported.
      
      * When used in OpenGL mode for both, we render into an FBO export the
      texture ID then it's up to the effect to render that into a scene.
      
      * When using software QtQuick rendering we blit into an image, upload
      that into a KWinGLTexture which serves as an abstraction layer and
      render that into the scene.
      
      * When using GL for QtQuick and XRender/QPainter in kwin everything is
      rendered into the internal FBO, blit and exported as an image.
      
      * When using software rendering for both an image gets passed directly.
      
      Mouse and keyboard events can be forwarded, only if the effect
      intercepts them.
      
      The class is meant to be generic enough that we can remove all the
      QtQuick code from Aurorae.
      
      The intention is also to replace EffectFrameImpl using this backend and
      we can kill all of the EffectFrame code throughout the scenes.
      
      The close button in present windows will also be ported to this,
      simplifiying that code base.
      
      Classes that handle the rendering and handling QML are intentionally
      split so that in the future we can have a declarative effects API create
      overlays from within the same context. Similar to how one can
      instantiate windows from a typical QML scene.
      
      Notes:
      I don't like how I pass the kwin GL context from the backends into the
      effect, but I need something that works with the library separation. It
      also currently has wayland problem if I create a QOpenGLContext before
      the QPA is set up with a scene - but I don't have anything better?
      
      I know for the EffectFrame we need an API to push things through the
      effects stack to handle blur/invert etc. Will deal with that when we
      port the EffectFrame.
      
      Test Plan: Used in an effect
      
      Reviewers: #kwin, zzag
      
      Reviewed By: #kwin, zzag
      
      Subscribers: zzag, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D24215
      40b0296d
  9. 19 Sep, 2019 1 commit
    • Vlad Zahorodnii's avatar
      Use nullptr everywhere · 62a7db70
      Vlad Zahorodnii authored
      Summary:
      Because KWin is a very old project, we use three kinds of null pointer
      literals: 0, NULL, and nullptr. Since C++11, it's recommended to use
      nullptr keyword.
      
      This change converts all usages of 0 and NULL literal to nullptr. Even
      though it breaks git history, we need to do it in order to have consistent
      code as well to ease code reviews (it's very tempting for some people to
      add unrelated changes to their patches, e.g. converting NULL to nullptr).
      
      Test Plan: Compiles.
      
      Reviewers: #kwin, davidedmundson, romangg
      
      Reviewed By: #kwin, davidedmundson, romangg
      
      Subscribers: romangg, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D23618
      62a7db70
  10. 06 Sep, 2019 1 commit
  11. 31 Aug, 2019 1 commit
    • Vlad Zahorodnii's avatar
      Switch to Q_ASSERT · 7a3722b4
      Vlad Zahorodnii authored
      Summary:
      Switch to Q_ASSERT in order to make code a bit more consistent. We have
      places where both assert and Q_ASSERT are used next to each other. Also,
      distributions like Ubuntu don't strip away assert(), let's hope that
      things are a bit different with Q_ASSERT.
      
      Test Plan: Compiles.
      
      Reviewers: #kwin, davidedmundson
      
      Reviewed By: #kwin, davidedmundson
      
      Subscribers: romangg, davidedmundson, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D23605
      7a3722b4
  12. 07 Aug, 2019 1 commit
    • Roman Gilg's avatar
      Split Compositor class in Wayland and X11 child classes · 1db84a2b
      Roman Gilg authored
      Summary:
      This patch is a first take at splitting up of the Compositor class into
      Wayland and X11 child classes.
      
      In this first patch we mostly deal with setup and teardown procedures.
      A future goal is to further differentiate the compositing part itself too.
      
      Test Plan: Manually X from VT and Wayland nested. Autotests pass.
      
      Reviewers: #kwin
      
      Subscribers: sbergeron, anthonyfieroni, zzag, kwin
      
      Tags: #kwin
      
      Maniphest Tasks: T11071
      
      Differential Revision: https://phabricator.kde.org/D22195
      1db84a2b
  13. 09 Jul, 2019 2 commits
  14. 29 Jun, 2019 1 commit
  15. 27 Mar, 2019 1 commit
    • Erik Kurzinger's avatar
      [platforms/x11] Force glXSwapBuffers to block with NVIDIA driver · 3ce5af5c
      Erik Kurzinger authored
      Summary:
      The NVIDIA implementation of glXSwapBuffers will, by default, queue up
      to two frames for presentation before blocking. KWin's compositor,
      however, assumes that calls to glXSwapBuffers will always block until
      the next vblank when rendering double buffered. This assumption isn't
      valid, as glXSwapBuffers is specified as being an implicit glFlush,
      not an implicit glFinish, and so it isn't required to block. When this
      assumption is violated, KWin's frame timing logic will
      break. Specifically, there will be extraneous calls to
      setCompositeTimer with a waitTime of 0 after the non-blocking buffer
      swaps, dramatically reducing desktop responsiveness. To remedy this,
      a call to glXWaitGL was added by Thomas Luebking after glXSwapBuffers
      in 2015 (see bug 346275, commit
      8bea96d7). That glXWaitGL call is
      equivalent to a glFinish call in direct rendering, so it was a good
      way to make glXSwapBuffers behave as though it implied a glFinish
      call.
      
      However, the NVIDIA driver will by default do a busy wait in glFinish,
      for reduced latency. Therefore that change dramatically increased CPU
      usage. GL_YIELD can be set to USLEEP (case insensitive) to change
      the behavior and use usleep instead. When using the NVIDIA driver,
      KWin will disable vsync entirely if GL_YIELD isn't set to USLEEP
      (case sensitive, a bug in KWin).
      
      However, the NVIDIA driver supports another environment variable,
      __GL_MaxFramesAllowed, which can be used to control how many frames
      may be queued by glXSwapBuffers. If this is set to 1 the function
      will always block until retrace, in line with KWin's expectations.
      This allows the now-unnecessary call to glXWaitGL to be removed along
      with the logic to conditionally disable vsync, providing a better
      experience on NVIDIA hardware.
      
      Reviewers: #kwin, davidedmundson, zzag
      
      Reviewed By: #kwin, davidedmundson, zzag
      
      Subscribers: kwin, davidedmundson, zzag
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D19867
      3ce5af5c
  16. 20 Mar, 2019 1 commit
    • Erik Kurzinger's avatar
      [platforms/x11] Force glXSwapBuffers to block with NVIDIA driver · 22a441e0
      Erik Kurzinger authored
      Summary:
      The NVIDIA implementation of glXSwapBuffers will, by default, queue up
      to two frames for presentation before blocking. KWin's compositor,
      however, assumes that calls to glXSwapBuffers will always block until
      the next vblank when rendering double buffered. This assumption isn't
      valid, as glXSwapBuffers is specified as being an implicit glFlush,
      not an implicit glFinish, and so it isn't required to block. When this
      assumption is violated, KWin's frame timing logic will
      break. Specifically, there will be extraneous calls to
      setCompositeTimer with a waitTime of 0 after the non-blocking buffer
      swaps, dramatically reducing desktop responsiveness. To remedy this,
      a call to glXWaitGL was added by Thomas Luebking after glXSwapBuffers
      in 2015 (see bug 346275, commit
      8bea96d7). That glXWaitGL call is
      equivalent to a glFinish call in direct rendering, so it was a good
      way to make glXSwapBuffers behave as though it implied a glFinish
      call.
      
      However, the NVIDIA driver will by default do a busy wait in glFinish,
      for reduced latency. Therefore that change dramatically increased CPU
      usage. GL_YIELD can be set to USLEEP (case insensitive) to change
      the behavior and use usleep instead. When using the NVIDIA driver,
      KWin will disable vsync entirely if GL_YIELD isn't set to USLEEP
      (case sensitive, a bug in KWin).
      
      However, the NVIDIA driver supports another environment variable,
      __GL_MaxFramesAllowed, which can be used to control how many frames
      may be queued by glXSwapBuffers. If this is set to 1 the function
      will always block until retrace, in line with KWin's expectations.
      This allows the now-unnecessary call to glXWaitGL to be removed along
      with the logic to conditionally disable vsync, providing a better
      experience on NVIDIA hardware.
      
      Reviewers: #kwin, davidedmundson, zzag
      
      Reviewed By: #kwin, davidedmundson, zzag
      
      Subscribers: kwin, davidedmundson, zzag
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D19867
      22a441e0
  17. 22 Jan, 2019 1 commit
  18. 20 Nov, 2017 1 commit
    • Pierre Willenbrock's avatar
      Allow glXChooseFBConfig to return sRGB capable fbconfig · 9300aa82
      Pierre Willenbrock authored
      Mesa's glXChooseFBConfig will not return any sRGB capable fbconfig when it
      is not explicitly asked for. On some systems, the only ARGB32 visual is
      paired with an sRGB capable fbconfig, so application windows using ARGB32
      visuals would fail to display.
      
      BUG: 387159
      FIXED-IN: 5.11.4
      9300aa82
  19. 30 Sep, 2017 1 commit
    • Martin Flöser's avatar
      Move SceneOpenGL into a dedicated plugin · 8ae37c42
      Martin Flöser authored
      Summary:
      Unfortunately a rather large change which required more refactoring than
      initially expected. The main problem was that some parts needed to go
      into platformsupport so that the platform plugins can link them. Due to
      the rather monolithic nature of scene_opengl.h a few changes were
      required:
      * SceneOpenGL::Texture -> SceneOpenGLTexture
      * SceneOpenGL::TexturePrivate -> SceneOpenGLTexturePrivate
      * texture based code into dedicated files
      * SwapProfiler code into dedicated files
      * SwapProfiler only used in x11 variants
      * Safety checks for OpenGL scene moved into the new plugin
      * signal declared in SceneOpenGL moved to Scene, so that we don't need
      to include SceneOpenGL in composite
      
      Test Plan: Nested OpenGL compositor works
      
      Reviewers: #kwin, #plasma
      
      Subscribers: plasma-devel, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D7740
      8ae37c42
  20. 19 Aug, 2017 1 commit
  21. 12 Aug, 2017 1 commit
    • Martin Flöser's avatar
      Move the X11 specific OverlayWindow into the platform/x11 · b4a79d30
      Martin Flöser authored
      Summary:
      The overlay window is only needed for the X11 based compositors. Given
      that it is better suited in the X11 platform. Unfortunately it is not
      possible to completely move it into the platform plugin as it is still
      referenced in KWin core (e.g. SceneXRender). Due to that the
      OverlayWindow in KWin core is turned into a pure virtual class with the
      implementation being moved into the plugin.
      
      The platform API gains a new virtual factory method which is only
      implemented in the X11 platform.
      
      Test Plan: Compiles
      
      Reviewers: #kwin, #plasma
      
      Subscribers: plasma-devel, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D7193
      b4a79d30
  22. 29 Jul, 2017 1 commit
  23. 17 Jul, 2017 1 commit
    • Martin Flöser's avatar
      Require C++14 · ea5d611d
      Martin Flöser authored
      Summary:
      KWin already used C++14 constructs in a conditional way. This doesn't
      make much sense today, it's better to just require C++14.
      
      For KWin only gcc and clang are currently compilers of relevance. Gcc
      supports C++14 since version 5 and defaults to C++14 since 6.1 [1].
      Clang supports C++14 since version 3.4 [2].
      
      An overview of compiler support in various distributions:
      * Debian stable (stretch): gcc 6.3, clang 3.8
      * Debian oldstable (jessie): 4.9, clang 3.5
      * Ubuntu 17.04: gcc 6.1, clang 3.8
      * Ubuntu 16.04: gcc 5.3, clang 3.8
      * openSUSE Tumbleweed: gcc 7.1, clang 4.0
      * openSUSE Leap 42.3: gcc ?, clang ? [3]
      * FreeBSD: clang >= 34 in ports
      * Slackware 14.2: gcc 5.3
      
      This overview shows that every distro out there has at least one
      supported compiler which can still compile KWin with this change.
      
      [1] https://gcc.gnu.org/projects/cxx-status.html#cxx14
      [2] https://clang.llvm.org/cxx_status
      [3] Sorry I fail to understand openSUSE's package repository.
          It seems that there is gcc 7 available, but gcc package is 4.8
      
      Test Plan: Compiles on my neon system
      
      Reviewers: #plasma
      
      Subscribers: plasma-devel, kwin, #kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D6634
      ea5d611d
  24. 01 Jul, 2017 1 commit
  25. 26 Jun, 2017 1 commit
  26. 22 Nov, 2016 1 commit
  27. 16 Nov, 2016 3 commits
    • Martin Flöser's avatar
      Remove KWin::display from kwinglobals · 346619aa
      Martin Flöser authored
      Summary:
      And finally nothing inside libkwineffects, libkwinglutils,
      libkwinxrenderutils and kwineffect and kwin core uses KWin::display.
      We are finally XLib free!
      
      This change drops KWin::display and removes the include to QX11Info from
      kwinglobals.h. And the libraries no longer need to link X11Extras.  Due
      to that removal a few seeming unrelated changes are required to add the
      include where needed and linkage to X11Extras.
      
      The biggest change is to x11 platform plugin which still needs the
      display and caches it in the Platform and passes it to various places in
      a way that the code doesn't need to be adjusted.
      
      Reviewers: #kwin, #plasma_on_wayland
      
      Subscribers: plasma-devel, kwin
      
      Tags: #plasma_on_wayland, #kwin
      
      Differential Revision: https://phabricator.kde.org/D3337
      346619aa
    • Martin Flöser's avatar
      Pass function ptr to resolve glFunctions to initGL · d7fa8276
      Martin Flöser authored
      Summary:
      KWin still resolves some OpenGL function pointers. For that it needs to
      use either eglGetProcAddress or glxGetProcAddress. With other words the
      method to resolve needs to know whether it is egl or glx and needs both
      a dependency to egl and glx. Especially the dependency to glx is ugly as
      that pulls in XLib into our library.
      
      The way so far was to pass an enum value to the initGL method to know
      whether it's EGL or GLX. With this change the enum value is removed and
      replaced by a function pointer to resolve the methods.
      
      This simplifies the resolve code and allows to completely remove the glx
      variant we still had in the library. Thus kwinglutils library is now glx
      and XLib free.
      
      Test Plan: nested KWin with OpenGL/EGL still works
      
      Reviewers: #kwin, #plasma_on_wayland
      
      Subscribers: plasma-devel, kwin
      
      Tags: #plasma_on_wayland, #kwin
      
      Differential Revision: https://phabricator.kde.org/D3336
      d7fa8276
    • Martin Flöser's avatar
      Move resolving glxSwapIntervalMesa into platform plugin · feac312e
      Martin Flöser authored
      Summary:
      No need to resolve glx methods through the shared lib. At the moment
      this duplicates some code, but will be cleaned up with a follow up
      change.
      
      Reviewers: #kwin, #plasma_on_wayland
      
      Subscribers: plasma-devel, kwin
      
      Tags: #plasma_on_wayland, #kwin
      
      Differential Revision: https://phabricator.kde.org/D3335
      feac312e