1. 10 Nov, 2015 3 commits
  2. 09 Nov, 2015 1 commit
  3. 06 Nov, 2015 2 commits
    • Bhushan Shah's avatar
      [wayland] Introduce ShellClient::isLockScreen method · 3a137198
      Bhushan Shah authored
      This allows to check if specific ShellClient is from LockScreen or not,
      as well as this adds method to verify if ShellClient is from input
      method like maliit.
      Now that KWin knows about which window is from Screenlocker it can apply
      various security restrictions like no other window then greeter is on
      top of it.
      Reviewed-By: Martin Gräßlin
    • Bhushan Shah's avatar
      [wayland] Adapt to changes in the kscreenlocker · c957b145
      Bhushan Shah authored
      Initialize is no longer called by KSldApp ctor, and also pass
      KWayland::Server::Display* to KSldApp.
      Reviewed-By: Martin Gräßlin
  4. 05 Nov, 2015 1 commit
  5. 22 Oct, 2015 1 commit
  6. 10 Sep, 2015 1 commit
    • Martin Flöser's avatar
      [wayland] Add support for DpmsInterface · 43f6c1e0
      Martin Flöser authored
      Our server announces the DpmsManagerInterface and in the DRM backend
      we announce support for Dpms on the OutputInterface (if the Output
      supports it) and we connect to changing Dpms requests.
  7. 02 Sep, 2015 1 commit
  8. 25 Aug, 2015 6 commits
  9. 15 Jul, 2015 1 commit
    • Martin Flöser's avatar
      [wayland] Shadow gains support for a Wayland protocol · df1146bf
      Martin Flöser authored
      For Wayland clients we now are able to get shadows.
      Internally this reuses large parts of the X11 implementation. This
      could be improved to make the Scene's better aware of the Wayland
      shadow, so that less memory is needed.
  10. 09 Jul, 2015 2 commits
    • Martin Flöser's avatar
    • Martin Flöser's avatar
      [wayland] Improve creation of KWayland::Server::PlasmaWindowInterface · 72635101
      Martin Flöser authored
      The creation of PlasmaWindowInterface is moved from WaylandServer into
      AbstractClient. This allows the sub classes to better control when to
      create/destroy the Client.
      For creation it's bound to becoming visible - that is Windows which are
      only created but never shown are not announced at all.
      For Client it's destroyed with the normal tear-down of a Client, for
      ShellClient it's destroyed on unmapped (which also means a new one
      will be created again in case of another mapping of the surface).
      As a side effect, this works around the problem that ShellClients do not
      yet get destroyed for QtWayland's menus (needs further investigation).
  11. 29 Jun, 2015 1 commit
  12. 20 Jun, 2015 1 commit
    • Martin Flöser's avatar
      [wayland] Export themed icon name to PlasmaWindow interface · 8b6fef45
      Martin Flöser authored
      If the icon doesn't have a name, we pass the generic xorg icon. Most
      likely our xwayland clients won't have a theme name, so giving them
      the xorg icon seems a good enough work around. If we would want to
      pass the real icon for xwayland clients we would need a way to
      serialize them which seems like quite some needless overhead for legacy
      applications. Can be considered for the future nevertheless.
  13. 19 Jun, 2015 2 commits
  14. 18 Jun, 2015 2 commits
  15. 17 Jun, 2015 2 commits
  16. 16 Jun, 2015 1 commit
  17. 13 Jun, 2015 2 commits
    • Martin Flöser's avatar
      [wayland] Add support for PlasmaWindowManagement interface · 859a3bb5
      Martin Flöser authored
      So far this only allows to trigger show desktop functionality and exports
      the state.
      In future this should be restricted to just one dedicated desktop shell
    • Halla Rempt's avatar
      [wayland] Add a command-line option to start an input method server · 98bcdbe7
      Halla Rempt authored
      Input-method servers, like maliit, need to be known to KWin since KWin
      needs to know about virtual keyboards. Virtual keyboards should be shown
      as OSD layers, and they are one of the types of windows that actually
      should be showable when the lock screen is active.
      kwin_wayland --inputmethod /path/to/your/input-server
      tries to start the input server. The input-server's window never gets
      keyboard focus and is shown on top of all windows except for KWin's
      internal clients.
  18. 09 Jun, 2015 2 commits
  19. 28 May, 2015 2 commits
  20. 27 May, 2015 1 commit
    • Martin Flöser's avatar
      [wayland] Place ShellClients · 90a68145
      Martin Flöser authored
      When a ShellClient is added and it's not internal, it get placed just
      like any other Client. This needs to happen after the initial size is
      Please note: this breaks the positioning of popup windows (e.g. menus)
      as they are placed like any other Client. This needs proper popup support
      which right now does not yet exist and thus is not much difference to
  21. 21 May, 2015 3 commits
  22. 18 May, 2015 2 commits
    • Martin Flöser's avatar
      [wayland] ShellClient can reference an internal QWindow · 7d152991
      Martin Flöser authored
      If the ShellClient got created for a Qt internal window, we try to
      find the QWindow and if we get one, we use the geometry directly as
      it got set by KWin in the first place.
      Also a windowId() is added to ShellClient which can be used by the
      effect system to find an EffectWindow. If it's an internal QWindow
      we just use that window id. For other clients we still need some
      smart solution.
    • Martin Flöser's avatar
      [wayland] Flush QtWaylands wl_display and KWin's wayland server when processing events · 74ae2f50
      Martin Flöser authored
      QtWayland and mesa might dead lock KWin if we start rendering a QWindow
      before Qt/Mesa got the last frame callback. They perform blocking wayland
      event reading on the main gui thread which makes it impossible for KWin
      to do the compositing and send the callback.
      To workaround this problem we fake a frameRendered directly after each
      damage event for a Qt internal window. Unfortunately this is not yet
      completely sufficient, thus we also need to ensure that the wayland
      events are processed before any events are processed which would cause
      a repaint and block. Thus we first flush QtWayland's wl_display and then
      our Server connection. If there were any damage events we can be sure
      that the frameRendered is sent before Qt attempts to render.