1. 02 Feb, 2014 1 commit
  2. 01 Feb, 2014 1 commit
    • Jasper St. Pierre's avatar
      Start moving X11-specific code to window-x11.c · f7097e6f
      Jasper St. Pierre authored
      The goal here is to make MetaWindow represent a toplevel, managed window,
      regardless of if it's X11 or Wayland, and build an abstraction layer up.
      Right now, most of the X11 code is in core/ and the wayland code in wayland/,
      but in the future, I want to move a lot of the X11 code to a new toplevel, x11/.
      f7097e6f
  3. 13 Jan, 2014 1 commit
  4. 07 Jan, 2014 1 commit
  5. 09 Dec, 2013 2 commits
  6. 05 Dec, 2013 1 commit
    • Jasper St. Pierre's avatar
      Support X button events again · fa65c380
      Jasper St. Pierre authored
      Do this by duplicating the current code and porting it to use
      X again. A better approach would involve our own event structures,
      and I really don't want to do that right now. We can clean this up
      later.
      fa65c380
  7. 25 Nov, 2013 1 commit
  8. 21 Nov, 2013 1 commit
  9. 19 Nov, 2013 3 commits
  10. 12 Nov, 2013 2 commits
  11. 16 Sep, 2013 3 commits
  12. 03 Sep, 2013 2 commits
  13. 29 Aug, 2013 1 commit
  14. 26 Aug, 2013 1 commit
  15. 17 Aug, 2013 1 commit
  16. 13 Aug, 2013 1 commit
  17. 10 Aug, 2013 3 commits
    • Robert Bragg's avatar
      Add support for stacking X and Wayland windows together · 40e820f5
      Robert Bragg authored
      This breaks down the assumptions in stack-tracker.c and stack.c that
      Mutter is only stacking X windows.
      
      The stack tracker now tracks windows using a MetaStackWindow structure
      which is a union with a type member so that X windows can be
      distinguished from Wayland windows.
      
      Some notable changes are:
      
      Queued stack tracker operations that affect Wayland windows will not be
      associated with an X serial number.
      
      If an operation only affects a Wayland window and there are no queued
      stack tracker operations ("unvalidated predictions") then the operation
      is applied immediately since there is no server involved with changing
      the stacking for Wayland windows.
      
      The stack tracker can no longer respond to X events by turning them into
      stack operations and discarding the predicted operations made prior to
      that event because operations based on X events don't know anything
      about the stacking of Wayland windows.
      
      Instead of discarding old predictions the new approach is to trust the
      predictions but whenever we receive an event from the server that
      affects stacking we cross-reference with the predicted stack and check
      for consistency. So e.g. if we have an event that says ADD window A then
      we apply the predictions (up to the serial for that event) and verify
      the predicted state includes a window A. Similarly if an event says
      RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for
      that event) and verify that window B is above C.
      
      If we ever receive spurious stacking events (with a serial older than we
      would expect) or find an inconsistency (some things aren't possible to
      predict from the compositor) then we hit a re-synchronization code-path
      that will query the X server for the full stacking order and then use
      that stack to walk through our combined stack and force the X windows to
      match the just queried stack but avoiding disrupting the relative
      stacking of Wayland windows. This will be relatively expensive but
      shouldn't be hit for compositor initiated restacking operations where
      our predictions should be accurate.
      
      The code in core/stack.c that deals with synchronizing the window stack
      with the X server had to be updated quite heavily. In general the patch
      avoids changing the fundamental approach being used but most of the code
      did need some amount of re-factoring to consider what re-stacking
      operations actually involve X or not and when we need to restack X
      windows we sometimes need to search for a suitable X sibling to restack
      relative too since the closest siblings may be Wayland windows.
      40e820f5
    • Robert Bragg's avatar
      wayland: Adds basic hybrid X + Wayland support · f9a11b3b
      Robert Bragg authored
      
      
      This adds support for running mutter as a hybrid X and Wayland
      compositor. It runs a headless XWayland server for X applications
      that presents wayland surfaces back to mutter which mutter can then
      composite.
      
      This aims to not break Mutter's existing support for the traditional X
      compositing model which means a single build of Mutter can be
      distributed supporting the traditional model and the new Wayland based
      compositing model.
      
      TODO: although building with --disable-wayland has at least been tested,
      I still haven't actually verified that running as a traditional
      compositor isn't broken currently.
      
      Note: At this point no input is supported
      
      Note: multiple authors have contributed to this patch:
      Authored-by: default avatarRobert Bragg <robert@linux.intel.com>
      Authored-by: default avatarNeil Roberts <neil@linux.intel.com>
      Authored-by: Rico Tzschichholz.
      Authored-by: default avatarGiovanni Campagna <gcampagna@src.gnome.org>
      f9a11b3b
    • Robert Bragg's avatar
      Track the X Shape input region and use it for picking · 531be6c4
      Robert Bragg authored
      We now track whether a window has an input shape specified via the X
      Shape extension. Intersecting that with the bounding shape (as required
      by the X Shape extension) we use the resulting rectangles to paint
      window silhouettes when picking. As well as improving the correctness of
      picking this should also be much more efficient because typically when
      only picking solid rectangles then the need to actually render and issue
      a read_pixels request can be optimized away and instead the picking is
      done on the cpu.
      531be6c4
  18. 22 May, 2013 1 commit
    • Dan Winship's avatar
      display: clean up focus_window vs expected_focus_window · 7a4c808e
      Dan Winship authored
      Mutter previously defined display->focus_window as the window that the
      server says is focused, but kept display->expected_focus_window to
      indicate the window that we have requested to be focused. But it turns
      out that "expected_focus_window" was almost always what we wanted.
      
      Make MetaDisplay do a better job of tracking focus-related requests
      and events, and change display->focus_window to be our best guess of
      the "currently" focused window (ie, the window that will be focused at
      the time when the server processes the next request we send it).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=647706
      7a4c808e
  19. 14 Mar, 2013 2 commits
    • Owen W. Taylor's avatar
      Make handling of windows that don't respond to _NET_WM_SYNC_REQUEST reliable · 97a4cc8c
      Owen W. Taylor authored
      Previously, we were handling failure to respond to _NET_WM_SYNC_REQUEST
      in the code path for throttling motion events. But this meant that
      if a window didn't respond to _NET_WM_SYNC_REQUEST and there were no
      motion events - for a keyboard resize, or after the end of the grab
      operation - it would end up in a stuck state.
      
      Use a separate per-window timeout to reliably catch the failure to respond
      to _NET_WM_SYNC_REQUEST.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=694046
      97a4cc8c
    • Owen W. Taylor's avatar
      Fix freezing of windows with keyboard resizing · 592374bc
      Owen W. Taylor authored
      During resizing we froze window updates when configuring the
      window, and unfroze the window updates when processing the
      next resize. This wasn't absolutely reliable, because we might
      not have a next resize. Instead tie window freezing more
      directly to the current sync request value - a window is
      frozen until it catches up with the last value we sent it
      in _NET_WM_SYNC_REQUEST.
      
      Testing with unresponsive clients showed that there was a bug
      where window->disable_sync once set, would not actually disable
      sync, but it *would* disable noticing that the client was
      unresponsive for the next resize. Fix that by checking for
      ->disable_sync before sending _NET_WM_SYNC_REQUEST.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=694046
      592374bc
  20. 20 Feb, 2013 1 commit
    • Ray Strode's avatar
      window: fix meta_window_is_remote across hostname changes · 2cafb8be
      Ray Strode authored
      meta_window_is_remote compares a cached copy of the system hostname
      with the hostname of the client window
      (as presented by the WM_CLIENT_MACHINE property).
      
      Of course, the system hostname can change at any time, so caching
      it is wrong. Also, the WM_CLIENT_MACHINE property won't necessarily
      change when the system hostname changes, so comparing it with the
      new system hostname is wrong, too.
      
      This commit makes the code call gethostname() at the time
      WM_CLIENT_MACHINE is set, check whether it's remote then, and cache
      that value, rather than comparing potentially out of sync hostnames
      later.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=688716
      2cafb8be
  21. 14 Feb, 2013 1 commit
  22. 13 Feb, 2013 5 commits
  23. 06 Feb, 2013 4 commits