1. 28 Aug, 2018 2 commits
  2. 27 Aug, 2018 16 commits
    • Anders Jonsson's avatar
      Update Swedish translation · 388d0656
      Anders Jonsson authored
      388d0656
    • Jonas Ådahl's avatar
      window/wayland: Don't recursive indefinitely when updating monitor · e191c21e
      Jonas Ådahl authored
      When we update the main monitor, there is a rule that makes it so that
      popup windows use the same main monitor as their parent. In the commit
      f4d07caa the call that updates and
      fetches the main monitor of the toplevel accidentally changed to update
      from itself, causing a indefinite recursion eventually resulting in a
      crash.
      
      Closes: #279
      e191c21e
    • Jonas Ådahl's avatar
      window: Keep windows with placement rule attached to parent · 5376c31a
      Jonas Ådahl authored
      A window placed using a placement rule should keep that relative
      position even if the parent window moves, as the position tied to the
      parent window, not to the stage. Thus, if the parent window moves, the
      child window should move with it.
      
      In the implementation in this commit, the constraints engine is not
      used when repositioning the children; the window is simply positioned
      according to the effective placement rule that was derived from the
      initial constraining, as the a xdg_popup at the moment cannot move
      (relative its parent) after being mapped.
      
      Closes: #274
      5376c31a
    • Jonas Ådahl's avatar
      wayland/gtk-shell: Handle requests after toplevel was unmanaged · ca5b27ba
      Jonas Ådahl authored
      As with xdg-toplevel, a gtk-surface can be unmanaged by the compositor
      without the client knowing about it, meaning the client may still send
      updates and make requests. Handle this gracefully by ignoring them. The
      client needs to reset all the state anyway, if it wants to remap the
      same surface.
      
      #240
      ca5b27ba
    • Jonas Ådahl's avatar
      wayland/legacy-xdg-shell: Handle requests after toplevel was unmanaged · 64df6276
      Jonas Ådahl authored
      As with xdg-toplevel proper, a legacy xdg-toplevel can be unmanaged by
      the compositor without the client knowing about it, meaning the client
      may still send updates and make requests. Handle this gracefully by
      ignoring them. The client needs to reassign the surface the legacy
      xdg-toplevel role again, if it wants to remap the same surface, meaning
      all state would be reset anyway.
      
      Closes: #240
      64df6276
    • Jonas Ådahl's avatar
      wayland/legacy-xdg-shell: Cache frame callbacks if toplevel is unmanaged · a740f50c
      Jonas Ådahl authored
      A toplevel window can be unmanaged without the client knowing it (e.g. a
      modal dialog being unmapped together with its parent. When this has
      happened, take frame callbacks queued on a commit and cache them on the
      generic surface queue. If the toplevel is to be remapped because the
      surface was reassigned the toplevel role, the cached frame callbacks
      will be queued on the surface actor and dispatched accordingly.
      
      #240
      a740f50c
    • Jonas Ådahl's avatar
      wayland/xdg-shell: Handle requests after toplevel was unmanaged · 5fd0f62a
      Jonas Ådahl authored
      A window can be unmanaged without asking the client to do it, for
      example as a side effect of a parent window being unmanaged, if the
      child window was a attached dialog.
      
      This means that the client might still make requests post updates to it
      after that it was unmapped. Handle this gracefully by NULL-checking the
      surface's MetaWindow pointer. We're not loosing any state due to this,
      as if the client wants to map the same surface again, it needs to either
      reassign it the toplevel role, or reset the xdg-toplevel, both resulting
      in all state being lost anyway.
      
      #240
      5fd0f62a
    • Jonas Ådahl's avatar
      wayland/xdg-shell: Cache frame callbacks if toplevel is unmanaged · 80d420ff
      Jonas Ådahl authored
      A toplevel window can be unmanaged without the client knowing it (e.g. a
      modal dialog being unmapped together with its parent. When this has
      happened, take frame callbacks queued on a commit and cache them on the
      generic surface queue. If the toplevel is to be remapped, either because
      the surface was reassigned the toplevel role, or if it was reset and
      remapped, the cached frame callbacks will be queued on the surface actor
      and dispatched accordingly.
      
      #240
      80d420ff
    • Jonas Ådahl's avatar
      wayland/xdg-shell: Cache pending frame callbacks on popup reset · 407d6294
      Jonas Ådahl authored
      A popup can be reset, and when that happens, window and actor are
      destroyed, and won't be created again unless it is reassigned the
      popup role.
      
      If a client queued frame callbacks when resetting a popup, the frame
      callbacks would be left in the pending state, as they were not queued on
      the actor, meaning we'd hit an assert about the frame callbacks not
      being handled. Fix this by caching them on the MetaWaylandSurface, so
      that they either are cleaned up on destruction, or queued on the actor
      would the surface be re-assigned the popup role.
      
      #240
      407d6294
    • Jonas Ådahl's avatar
      wayland/surface: Add API to cache frame callbacks · 0ace58d0
      Jonas Ådahl authored
      Sometimes it may be useful for roles to put callbacks in the generic
      surface frame callback queue. The surface frame callback queue will
      either eventually be processed on the next surface role assignment that
      places the frame callbacks in a role specific queue, processed at some
      other point in time by a role, or cleaned up on surface destruction.
      
      #240
      0ace58d0
    • Jonas Ådahl's avatar
      wayland/xdg-shell: Queue frame callbacks on new actor after resetting · d7917101
      Jonas Ådahl authored
      When a xdg-toplevel is reset, the window and actor are recreated, and
      all state is cleared. When this happened, we earlied out from the
      xdg-toplevel commit handler, which would mean that if the client had
      queued frame callbacks when resetting, they'd be left in the pending
      commit state, later hitting an assert as they were not handled.
      
      Fix this by queuing the frame callbacks no the new actor, so that they
      are emitted whenever the actor is eventually painted.
      
      #240
      d7917101
    • Carlos Garnacho's avatar
      wayland: Use geometry_scale on opaque regions · b30c907e
      Carlos Garnacho authored
      This was done for input regions in commit 718a89eb (Thanks Jonas
      for the archaeology!) but opaque regions follow the same scaling.
      This brings less evident issues as opaque regions are just used for
      culling optimizations.
      b30c907e
    • Carlos Garnacho's avatar
      wayland: Fix input/opaque regions calculation on hidpi · 784a774d
      Carlos Garnacho authored
      Commit 6a92c6f8 unintendedly broke input/opaque region calculations
      on hidpi. Most visible side effect is that clicking is only allowed
      in the upper-left quarter of windows.
      
      The surface coordinates are returned in logical unscaled buffer
      size. We're however interested in actor coordinates (thus real
      pixels) here.
      
      As it is a bit of a detour how the scale to be applied is calculated,
      refactor a meta_wayland_actor_surface_get_geometry_scale() function
      that we can use it here, and use it consistently for surface size and
      the given regions.
      784a774d
    • Jonas Ådahl's avatar
      window: Force update monitor on hot plugs · 8d3e0530
      Jonas Ådahl authored
      Commit a3da4b8d changed updating of
      window monitors to always use take affect when it was done from a
      non-user operation. This could cause feed back loops when a non-user
      driven operation would trigger the changing of a monitor, which itself
      would trigger changing of the monitor again due to a window scale
      change.
      
      The reason for the change, was that when the window monitor changed due
      to a hot plug, if it didn't actually change, eventually the window
      monitor pointer would be pointing to freed memory.
      
      Instead of force updating the monitor on all non-user operations, just
      do it on hot plugs. This allows for the feedback loop preventing logic
      to still do what its supposed to do, without risking dangling pointers
      on hot plugs.
      
      Related: #189
      Closes: #192
      8d3e0530
    • Jonas Ådahl's avatar
      window: Pass flag to meta_window_update_monitor() instead of bool · f4d07caa
      Jonas Ådahl authored
      The bool determines whether the call was directly from a user operation
      or not. To add more state into the call without having to add more
      boolenas, change the boolean to a flag (so far with 'none' and 'user-op'
      as possible values). No functional changes were made.
      
      #192
      f4d07caa
    • Milo Casagrande's avatar
      Update Italian translation · 8a6d502e
      Milo Casagrande authored
      8a6d502e
  3. 26 Aug, 2018 2 commits
  4. 24 Aug, 2018 1 commit
    • Jonas Ådahl's avatar
      renderer/native: Check calculated transform when creating view · ebafc256
      Jonas Ådahl authored
      The "backends: Move MetaOutput::crtc field into private struct"
      accidentally changed the view transform calculation code to assume that
      "MetaCrtc::transform" corresponds to the transform of the CRTC; so is
      not the case yet; one must calculate the transform from the logical
      monitor, and check whether it is supported by the CRTC using
      meta_monitor_manager_is_transform_handled(). This commit restores the
      old behaviour that doesn't use MetaCrtc::transform when calculating the
      view transform.
      
      Fixes: #216
      ebafc256
  5. 23 Aug, 2018 2 commits
  6. 21 Aug, 2018 4 commits
  7. 20 Aug, 2018 8 commits
  8. 19 Aug, 2018 1 commit
  9. 17 Aug, 2018 3 commits
    • Jonas Ådahl's avatar
      wayland/keyboard: Create a separate keymap shm file per resource · 21ce6f96
      Jonas Ådahl authored
      By using the shm file when sending the keymap to all clients, we
      effectively allows any client to change the keymap, as any client has
      the ability to change the content of the file. Sending a read-only file
      descriptor, or making the file itself read-only before unlinking, can
      be worked around by the client by using chmod(2) and open(2) on
      /proc/<pid>/<fd>.
      
      Using memfd could potentially solve this issue, but as the usage of
      mmap with MAP_SHARED is wide spread among clients, such a change can
      not be introduced without causing wide spread compatibility issues.
      
      So, to avoid allowing clients to interfere with each other, create a
      separate shm file for each wl_keyboard resource when sending the
      keymap. We could eventually do this per client, but in most cases,
      there will only be one wl_keyboard resource per client anyway.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=784206
      21ce6f96
    • Jonas Ådahl's avatar
      wayland/keyboard: Indentation fix · 323a806d
      Jonas Ådahl authored
      323a806d
    • Fabio Tomat's avatar
      Update Friulian translation · 84ac28cb
      Fabio Tomat authored
      84ac28cb
  10. 16 Aug, 2018 1 commit