1. 19 Oct, 2017 1 commit
    • Martin Flöser's avatar
      [QPA] Implement Screen on top of internal Screens API · abedb464
      Martin Flöser authored
      Summary:
      The test DontCrashUseractionsMenu (Waylandonly) found an issue in our
      screen handling implementation in the QPA. The code exposed a short time
      frame between the dummy screen getting destroyed and the first screen
      being added. This could result in a crash of KWin.
      
      There is actually no need to implement Screen on top of Wayland screen.
      KWin has all the knowledge, so we can also base this on top of the
      Screens API.
      
      Advantages:
       * no delays due to Wayland roundtrips
       * handle screen getting removed (was a TODO)
       * handle resolution changes (was a TODO)
      
      The new implementation has a disadvantage that it destroys and readds
      all screens whenever something around the screen changes. This shouldn't
      be an issue in practice as it's only for the internal QPA and thus only
      affects KWin internal windows which is placed in global coordinates
      anyway. If it turns out to be a problem we need to track better the
      screen changes - so far those were not tracked at all.
      
      Test Plan: Run a few unit tests which change screens
      
      Reviewers: #kwin, #plasma
      
      Subscribers: plasma-devel, kwin
      
      Tags: #kwin
      
      Differential Revision: https://phabricator.kde.org/D8345
      abedb464
  2. 31 Jul, 2017 1 commit
  3. 07 Feb, 2017 1 commit
  4. 28 Oct, 2016 2 commits
  5. 20 Jul, 2016 1 commit
    • Martin Flöser's avatar
      [plugins/qpa] Support SharingPlatformContext on the existing eglSurface and eglconfig · 44843f46
      Martin Flöser authored
      Summary:
      So far SharingPlatformContext was only used if the OpenGL context
      supports EGL_KHR_surfaceless_context. If not supported, KWin tried to
      create a context through the Wayland API. Unfortunately on hwcomposer
      platform this results in a crash as libhybris only supports the init
      of EGLDisplay for one native platform.
      
      This change tries to also use the SharingPlatformContext if there is
      an OpenGL context in general. It reuses the native EGLSurface created
      for the compositing scene and makes its own OpenGL context current on
      that surface, too. As KWin creates an FBO, it never renders to it, so
      it shouldn't matter at all.
      
      In order to prevent EGL_BAD_MATCH errors when making Qt's OpenGL context
      current also the EGLConfig from the scene is used to create the context.
      
      Test Plan: Tested on Nexus5 with qtvirtualkeyboard in KWin
      
      Reviewers: #kwin, #plasma_on_wayland
      
      Subscribers: plasma-devel, kwin
      
      Tags: #plasma_on_wayland, #kwin
      
      Differential Revision: https://phabricator.kde.org/D2231
      44843f46
  6. 02 Jun, 2016 2 commits
    • Martin Flöser's avatar
      [plugins/qpa] Handle case that qtvirtualkeyboard plugin is not available more gracefully · 5344bf16
      Martin Flöser authored
      We didn't check whether creating the QPlatfromInputContext worked and
      accessed the m_inputContext unconditionally which obviously crashed.
      
      Now the connects related to QInputMethods are not setup if we failed
      to create the QPlatfromInputContext.
      
      Reviewed-By: bshah
      5344bf16
    • Martin Flöser's avatar
      Integrate QtVirtualKeyboard into KWin/Wayland · f26f2fe1
      Martin Flöser authored
      Summary:
      The idea is to have KWin provide a virtual keyboard. To support this
      KWin uses the QT_IM_MODULE qtvirtualkeyboard and makes sure that the
      QPA plugin loads it.
      
      KWin has a new class VirtualKeyboard which acts as the focus object and
      the "proxy" for input methods. The QPA plugin ensures that this is the
      focusObject, so that all input method related events are sent to this
      class. From there it will be possible to delegate to other applications
      through the Wayland interfaces.
      
      Reviewers: #plasma
      
      Subscribers: plasma-devel
      
      Tags: #plasma
      
      Differential Revision: https://phabricator.kde.org/D1638
      f26f2fe1
  7. 07 Apr, 2016 2 commits
  8. 11 Mar, 2016 1 commit
  9. 10 Mar, 2016 1 commit
    • Martin Flöser's avatar
      [plugins/qpa] Add a dummy screen on startup · 51ee5142
      Martin Flöser authored
      Qt has problems initializing everything correctly if there is no screen
      at startup. E.g. the breeze widget style tries to initialize some pixmaps
      and this fails. In worst case hitting asserts in Qt (debug build).
      
      This change creates a dummy screen which gets destroyed as soon as there
      is a real screen.
      
      Reviewed-By: notmart and sebas
      51ee5142
  10. 10 Nov, 2015 1 commit
    • Martin Flöser's avatar
      [wayland] Fix cleanup handling on tear down · 8175562a
      Martin Flöser authored
      ASAN righly complained: we need to delete our Wayland objects before
      we destroy the internal client connection. Solved by better setting
      parent relationships in the QPA plugin and correctly delete objects
      in destroy of internal client connection.
      8175562a
  11. 25 Aug, 2015 2 commits
    • Martin Flöser's avatar
      [wayland] Create event dispatcher in QPA plugin · abb9bf13
      Martin Flöser authored
      We no longer need to have the event dispatcher created before starting
      the QApplication, thus we can leave it to the QPA plugin to creat it.
      
      Also we don't need to implement our own dispatcher any more but can
      use one from Qt5PlatformSupport as we link it anyways. The special
      need for dispatching the WaylandServer is no longer needed as we can
      explicitly dispatch it from the QPA plugin if needed.
      abb9bf13
    • Martin Flöser's avatar
      [wayland] Add a QPA plugin for kwin_wayland · 26b3569a
      Martin Flöser authored
      This introduces an own QPA plugin for KWin. QtWayland's plugin is not
      a good solution for KWin as QtWayland is meant for Wayland clients and
      not for a Wayland server. Given that it makes more sense to have a very
      minimal QPA plugin which supports the use cases we actually have.
      
      With our own QPA plugin we should be able to improve the following
      areas:
      * no need to create Wayland server before QApplication
      * Qt::BypassWindowManagerHint can be supported
      * no workaround for creating OpenGL context in main thread
      * sharing OpenGL context with Qt
      * OpenGL context for Qt on libhybris backend
      
      The plugin supports so far the following features:
      * creating a QPlatformWindow using KWayland::Client (ShellSurface)
      * creating a QPlatformBackingStore using a ShmPool
      * creating a QPlatformOpenGLContext with Wayland::EGL
      * or creating a QPlatformOpenGLContext which shares with KWin's scene
      * creating a QPlatformScreen for each KWayland::Client::Output
      * QPlatformNativeInterface compatible to QtWayland
      26b3569a