1. 10 Sep, 2019 1 commit
    • verdre's avatar
      Move tracking the number of touch sequences to ClutterInputDevice · f7189894
      verdre authored
      Move the tracking of the number of touch sequences on the screen to
      determine whether the sequence is pointer emulating from
      MetaGestureTracker to ClutterInputDevice. To do this, add new API to get
      the number of touches to ClutterInputDevice and remove the API from
      MetaGestureTracker.
      
      This is a first step for removing the sequence tracking inside
      meta-gesture-tracker, also it makes the check more clear since we can
      compare the number against 1 now (the number of sequences of the input
      device is already updated at this point).
      
      GNOME/mutter!790
      f7189894
  2. 07 Sep, 2019 2 commits
  3. 06 Sep, 2019 2 commits
  4. 05 Sep, 2019 8 commits
    • Christian Kirbach's avatar
      9065edfc
    • Jonas Ådahl's avatar
      monitor-manager/kms: Get hotplug events from MetaKms · 5111e339
      Jonas Ådahl authored
      This makes it clearer that MetaMonitorManagerKms keeps updated as
      MetaKms updates its state.
      
      GNOME/mutter!743
      5111e339
    • Jonas Ådahl's avatar
      kms/impl-device: Add and remove connectors on hot plug · 4cf82832
      Jonas Ådahl authored
      Connectors may disappear and appear on hot plugs, e.g. when a docking
      station is connected, so when processing a hot plug event, make sure we
      remove connectors that are now gone, and add new ones that have appeared
      since last time.
      
      Fixes: GNOME/mutter#728
      
      GNOME/mutter!743
      4cf82832
    • Jonas Ådahl's avatar
      kms: Add assert to check that the main thread is blocked on impl task · 35776c5d
      Jonas Ådahl authored
      This is so that we can have code in impl tasks that pokes at the main
      context objects.
      
      GNOME/mutter!743
      35776c5d
    • Jonas Ådahl's avatar
      window-actor: Handle changing surface actor on window reparenting · 2f27b8d5
      Jonas Ådahl authored
      The commit f2f4af0d missed one situation
      where mutter does things differently, i.e. changes what surface actor is
      associated with a given window actor: reparenting a Xwayland window when
      changing whether it is decorated.
      
      To summarize, there are three types of window actors:
      
      X11 window actors - directly tied to the backing X11 window. The
      corresponding surface actor is directly owned by the window actor and
      will never change.
      
      Wayland window actors - gets its surface actor from MetaWaylandSurface
      at construction. A single MetaWaylandSurface may create and destroy
      multiple window actors over time, but a single window actor will never
      change surface actor.
      
      Xwayland window actors - a mix between the above two types; the window
      corresponds to the X11 window, and so does the window actor, but the
      surface itself comes from the MetaWaylandSurface.
      
      Normally when a X11 window is unmapped, the corresponding MetaWindow is
      unmanaged. With Xwayland, this happens indirectly via the destruction of
      the wl_surface. The exception to this is windows that are reparented
      during changing their decoration state - in this case on plain X11, the
      MetaWindow stays alive. With Xwayland however, there is a race
      condition; since the MetaWindow is tied to the wl_surface, if we receive
      the new surface ID atom before the destruction of the old wl_surface,
      we'll try to associate the existing MetaWindow and MetaWindowActor with
      the new wl_surface, hitting the assert. If the surface destruction
      arrives first, the MetaWindow and MetaWindowActor will be disposed, and
      the we wouldn't hit the assert.
      
      To handle this race gracefully, reinstate handling of replacing the
      surface actor of an existing window actor, to handle this race, as it
      was handled before.
      
      Eventually, it should be reconsidered whether the MetaWindow lifetime is
      tied to the wl_surface or if it should be changed to be consistent with
      plain X11, as this re-exposes another bug where the X11 client and
      mutter will enter a feedback loop where the window is repeatedly
      remapped. See https://gitlab.freedesktop.org/xorg/xserver/issues/740.
      
      Fixes: GNOME/mutter#709
      
      GNOME/mutter!773
      2f27b8d5
    • Olivier Fourdan's avatar
      wayland/xdg-output: Fix xdg-output v3 support · be4131b3
      Olivier Fourdan authored
      When using xdg-output v3 or later, the Wayland compositor does not send
      xdg_output.done events which are deprecated.
      
      Instead, it should send a wl_output.done event for the matching
      wl_output.
      
      !771
      be4131b3
    • Gwan-gyeong Mun's avatar
      Update Korean translation · 854feafa
      Gwan-gyeong Mun authored
      854feafa
    • Rafael Fontenelle's avatar
      f423736a
  5. 04 Sep, 2019 1 commit
  6. 03 Sep, 2019 3 commits
  7. 02 Sep, 2019 12 commits
    • Jonas Ådahl's avatar
      x11: Trace XEvent processing · 3c0067dc
      Jonas Ådahl authored
      GNOME/mutter!765
      3c0067dc
    • Jonas Ådahl's avatar
      a957c2f0
    • Jonas Ådahl's avatar
      908203c7
    • Olivier Fourdan's avatar
      clutter/input-pointer-a11y: Restore pointer a11y on resume · 2f072af0
      Olivier Fourdan authored
      When suspending, the devices are removed and the virtual device
      associated with the corresponding core pointer is disposed.
      
      Add the pointer accessibility virtual device to the core pointer
      on resume to restore pointer accessibility on resume if enabled.
      
      GNOME/mutter!761
      2f072af0
    • Olivier Fourdan's avatar
      wayland/data-device: Restore keyboard focus on drag end · de98fb29
      Olivier Fourdan authored
      When starting a DnD operation, mutter would remove keyboard focus from
      the client, only to restore it on the data offer destroy.
      
      However, if the DnD fail, the keyboard focus is not restored, leaving
      the user unable to type in the focused window, even after clicking in
      the window.
      
      That issue would show only on first attempt, as further DnD attempts
      would destroy the previous data offer which would also restore the
      keyboard focus.
      
      Make sure we restore the keyboard focus on drag end as well.
      
      GNOME/mutter#747
      de98fb29
    • Olivier Fourdan's avatar
      wayland/data-device: Do not unset focus on drag start · 82c92177
      Olivier Fourdan authored
      On drag start, `data_device_start_drag()` issues a keyboard grab, which
      in turn will unset the current input focus.
      
      There is not need to unset the input focus in `data_device_start_drag()`
      as this is redone in `meta_wayland_keyboard_start_grab()`
      
      GNOME/mutter#747
      82c92177
    • Daniel van Vugt's avatar
      clutter: Introduce geometric picking · 14c706e5
      Daniel van Vugt authored
      Currently, Clutter does picking by drawing with Cogl and reading
      the pixel that's beneath the given point. Since Cogl has a journal
      that records drawing operations, and has optimizations to read a
      single pixel from a list of rectangle, it would be expected that
      we would hit this fast path and not flush the journal while picking.
      
      However, that's not the case: dithering, clipping with scissors, etc,
      can all flush the journal, issuing commands to the GPU and making
      picking slow. On NVidia-based systems, this glReadPixels() call is
      extremely costly.
      
      Introduce geometric picking, and avoid using the Cogl journal entirely.
      Do this by introducing a stack of actors in ClutterStage. This stack
      is cached, but for now, don't use the cache as much as possible.
      
      The picking routines are still tied to painting.
      
      When projecting the actor vertexes, do it manually and take the modelview
      matrix of the framebuffer into account as well.
      
      CPU usage on an Intel i7-7700, tested with two different GPUs/drivers:
      
        |         |     Intel | Nvidia |
        | ------: | --------: | -----: |
        | Moving the mouse:            |
        | Before  |       10% |    10% |
        | After   |        6% |     6% |
        | Moving a window:             |
        | Before  |       23% |    81% |
        | After   |       19% |    40% |
      
      Closes: #154,
              #691
      
      Helps significantly with: #283,
                                #590,
                                #700
      
      v2: Fix code style issues
          Simplify quadrilateral checks
          Remove the 0.5f hack
          Differentiate axis-aligned rectangles
      
      !189
      14c706e5
    • Daniel van Vugt's avatar
      clutter/point: Add ClutterPoint quarilateral testing API · a70823dd
      Daniel van Vugt authored
      Add a function to check whether a point is inside a quadrilateral
      by checking the cross product of vectors with the quadrilateral
      points, and the point being checked.
      
      If the passed quadrilateral is zero-sized, no point is ever reported
      to be inside it.
      
      This will be used by the next commit when comparing the transformed
      actor vertices.
      
      [feaneron: add a commit message and remove unecessary code]
      
      GNOME/mutter!189
      a70823dd
    • Rémi Bernon's avatar
    • Rémi Bernon's avatar
      core: Fix multiple reparent requests handling · 8f242f8b
      Rémi Bernon authored
      If window decoration is modified within a short period of time, mutter
      sometimes starts processing the second request before the first
      UnmapNotify event has been received. In this situation, it considers
      that the window is not mapped and does not expect another UnmapNotify /
      MapNotify event sequence to happen.
      
      This adds a separate counter to keep track of the pending reparents. The
      input focus is then restored when MapNotify event is received iff all
      the expected pending ReparentNotify events have been received.
      Signed-off-by: Rémi Bernon's avatarRémi Bernon <rbernon@codeweavers.com>
      
      !657
      8f242f8b
    • Mart Raudsepp's avatar
      36a14e65
    • Daniel van Vugt's avatar
      cogl: Remove GLX "threaded swap wait" used on Nvidia · 6ed5d2e2
      Daniel van Vugt authored
      Threaded swap wait was added for using together with the Nvidia GLX
      driver due to the lack of anything equivalent to the INTEL_swap_event
      GLX extension. The purpose was to avoid inhibiting the invocation of
      idle callbacks when constantly rendering, as the combination of
      throttling on swap-interval 1 and glxSwapBuffers() and the frame clock
      source having higher priority than the default idle callback sources
      meant they would never be invoked.
      
      This was solved in gbz#779039 by introducing a thread that took care of
      the vsync waiting, pushing frame completion events to the main thread
      meaning the main thread could go idle while waiting to draw the next
      frame instead of blocking on glxSwapBuffers().
      
      As of GNOME/mutter!363, the
      main thread will instead use prediction to estimate when the next frame
      should be drawn. A side effect of this is that even without
      INTEL_swap_event, we would not block as much, or at all, on
      glxSwapBuffers(), as at the time it is called, we have likely already
      hit the vblank, or will hit it soon.
      
      After having introduced the swap waiting thread, it was observed that
      the Nvidia driver used a considerable amount of CPU waiting for the
      vblank, effectively wasting CPU time. The need to call glFinish() was
      also problematic as it would wait for the frame to finish, before
      continuing. Due to this, remove the threaded swap wait, and rely only on
      the frame clock not scheduling frames too early.
      
      Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=781835
      Related: GNOME/mutter#700
      
      [jadahl: Rewrote commit message]
      
      GNOME/mutter!602
      6ed5d2e2
  8. 31 Aug, 2019 3 commits
  9. 29 Aug, 2019 1 commit
  10. 28 Aug, 2019 1 commit
  11. 27 Aug, 2019 6 commits