1. 17 Nov, 2020 1 commit
    • David Edmundson's avatar
      Allow small timeout intervals in IdleInterface · 9cf51bb1
      David Edmundson authored
      A threshold exists to stop users flooding the server for no reason.
      However, there is a usecase for small timeouts.
      rsibreak has a "please relax for 20 seconds" interface. Here it makes
      perfect sense to know if a user is active in small increments. The plan
      is to start a 1s timer and wait for that. Then we wait locally for 20s
      without a resume event.
  2. 16 Nov, 2020 1 commit
  3. 11 Nov, 2020 2 commits
    • Vlad Zahorodnii's avatar
      Safely end drag if the source data device gets destroyed · d70552f6
      Vlad Zahorodnii authored
      We cannot end a drag after the destroyed() signal for the source data
      device is emitted because DataDeviceInterface and its d pointer are gone
      by that time.
    • Vlad Zahorodnii's avatar
      Destroy all clients before destroying wl_display · e77f9ac2
      Vlad Zahorodnii authored
      One of the most disappointing things when writing autotests is dealing
      with a race condition where destructor requests are processed after all
      globals have been destroyed.
      With this change, the Display object will destroy all clients and their
      resources before destroying the wl_display object. The good thing about
      doing so is that shut down logic becomes simple. We don't have to assume
      that wl_resource objects can outlive their wl_global objects, etc. The
      bad thing is that it exposed a couple of pre-existing latent bugs in the
      data device and the xdg foreign code.
      closes #2
  4. 10 Nov, 2020 1 commit
  5. 09 Nov, 2020 1 commit
  6. 06 Nov, 2020 1 commit
  7. 05 Nov, 2020 3 commits
  8. 04 Nov, 2020 4 commits
  9. 03 Nov, 2020 3 commits
  10. 02 Nov, 2020 2 commits
  11. 31 Oct, 2020 1 commit
  12. 30 Oct, 2020 3 commits
  13. 29 Oct, 2020 2 commits
  14. 28 Oct, 2020 4 commits
  15. 26 Oct, 2020 1 commit
  16. 21 Oct, 2020 2 commits
  17. 20 Oct, 2020 1 commit
    • Adrien Faveraux's avatar
      move keyboard to the new approach and refactor the keyboard_interface · 8a6d17f2
      Adrien Faveraux authored and Bhushan Shah's avatar Bhushan Shah committed
      - Get rid of the KF5 deprecated methods related to keymap,
        kwayland-server is not source compatible with kwayland, so we don't
        need to keep the deprecated methods
      - Move the key repeat, modifiers and keymap handling fully into the
      - Get rid of some of the keyboard related code base from the
      Co-Author: Bhushan Shah <bshah@kde.org>
  18. 19 Oct, 2020 1 commit
    • Vlad Zahorodnii's avatar
      Simplify how infinite input regions are handled · 42246b78
      Vlad Zahorodnii authored
      Some input related code in kwin is mislead by the fact that when the
      input region is infinite, SurfaceInterface::input() is going to return
      an empty QRegion object.
      We cannot really do that because the client could have just set a valid
      empty wl_region object to ignore all input events.
      This change makes SurfaceInterface assign an actually infinite region
      when a NULL input region has been passed to set_input_region().
  19. 16 Oct, 2020 1 commit
    • Bhushan Shah's avatar
      input-method-v1: Fix bug regarding the modifier handling · cd72d896
      Bhushan Shah authored
      modifiers request by the input method is supposed to send the raw
      modifiers based on the keymap of the keyboard grabbed as result of the
      grab_keyboard request. If input method client is not using the keysym
      functionality it can decide to not send out the modifiers_map, since it
      is already known to compositor as part of keymap event sent by it.
      While at it also guard against empty modifiers_map, if this happens
      ideally compositor should handle that information based on the keymap
      sent out using grab_keyboard function, but since currently, we do not
      have the grab_keyboard implemented in here, send out the NoModifier if
      that happens.
  20. 14 Oct, 2020 4 commits
  21. 13 Oct, 2020 1 commit
    • Vlad Zahorodnii's avatar
      Properly handle destruction of XdgOutputV1Interface · 3987c0ae
      Vlad Zahorodnii authored
      The xdg-output spec omits whether the compositor has to destroy all xdg-
      output resources when the associated wl_output global is removed.
      This means that no xdg-output resource should be destroyed unless the
      client has called the destructor request; otherwise the client may panic
      due to protocol errors.
      Starting with Qt 5.15.2, it's okay to destroy generated wrapper objects
      without destroying associated resources. Destructor requests will be
      handled behind the scenes for inert and orphaned resources by code that
      is generated by qtwaylandscanner.
      BUG: 426293