1. 06 Jan, 2019 1 commit
  2. 05 Jan, 2019 6 commits
  3. 04 Jan, 2019 10 commits
    • Jonas Ådahl's avatar
      renderer/native: Use shadow fb on software GL if preferred · 173867c1
      Jonas Ådahl authored
      If a KMS device has the DRM_CAP_DUMB_PREFER_SHADOW and a software based
      GL driver is used, always use a shadow fb. This will speed up read backs
      in the llvmpipe OpenGL implementation, making blend operations faster.
      Fixes: #106
    • Georges Basile Stavracas Neto's avatar
      window-actor: Turn into an abstract class · df1384a8
      Georges Basile Stavracas Neto authored
      Now that everything is settled, from the initialization
      process to the subclasses to moving code to the compositor,
      MetaWindowActor can be a proper abstract class that cannot
      be instantiated.
      Thus, make MetaWindowActor an abstract class.
    • Georges Basile Stavracas Neto's avatar
      window-actor: Remove post_init() vfunc · 5fbeecaa
      Georges Basile Stavracas Neto authored
      This vfunc was added as a was to work around the convoluted
      initialization process. Now that we figured it out and moved
      the MetaWindowActor-specific initialization to constructed(),
      we can override that.
      Remove post_init() and use GObject.constructed() entirely.
    • Georges Basile Stavracas Neto's avatar
      window-actor: Move window actor creation to MetaCompositor · 54febd14
      Georges Basile Stavracas Neto authored
      MetaWindowActor breaks layering isolation by accessing
      and injecting itself into compositor->windows. This is
      a bad practice, and effecticely makes returning the
      new actor useless, since we doesn't even use the return
      Move window actor creation to under MetaCompositor and
      stop violating (too badly) the resposabilities of each
      component. This moves meta_window_actor_new() into
      Also, move the remaining initialization code to the
      GObject.constructed vfunc.
    • Georges Basile Stavracas Neto's avatar
      Document window and surface actors · 79528084
      Georges Basile Stavracas Neto authored
      Document the roles of MetaSurfaceActor and MetaWindowActor,
      and when their subclasses are used.
      (And this is actually the first real documentation under
    • Georges Basile Stavracas Neto's avatar
    • Georges Basile Stavracas Neto's avatar
      window-actor: Move X11-specific code to MetaWindowActorX11 · 80e3c1de
      Georges Basile Stavracas Neto authored
      MetaWindowActor handles sending _NET_WM_FRAME_* X atoms to
      clients - even pure Wayland clients.
      Now that we have Wayland- and X11-specific implementations of
      MetaWindowActor, we can delegate this to MetaWindowActorX11,
      and allow pure Wayland apps to not even connect to
      Do that by moving all the X11-specific code to the X11-specific
      MetaWindowActorX11 class. Add vfuncs to MetaWindowActorClass
      that are necessary for the move, namely:
       * pre_paint() and post_paint()
       * post_init()
       * frame_complete()
       * set_surface_actor()
       * queue_frame_drawn()
    • Georges Basile Stavracas Neto's avatar
      window-actor: Select X11 or Wayland actor based on client type · ac2f8cad
      Georges Basile Stavracas Neto authored
      X11 clients now have a MetaWindowActorX11 on the surface. Next
      commits will move the X11-specific code to MetaWindowActorX11.
    • Georges Basile Stavracas Neto's avatar
      Add MetaWindowActorX11 and MetaWindowActorWayland · 7e8fc135
      Georges Basile Stavracas Neto authored
      Those are stub specialized classes for MetaWindowActor. This will
      help ensuring that we do not execute X11-specific code paths on
      pure Wayland clients.
      The relationship between the window actor and the surface is the
       * Wayland: MetaWindowActorWayland + MetaSurfaceActorWayland
       * X11: MetaWindowActorX11 + MetaSurfaceActorX11
       * Xwayland: MetaWindowActorX11 + MetaSurfaceActorWayland
      It is not possible to have MetaWindowActorWayland backed by a
      MetaSurfaceActorX11 surface.
    • Georges Basile Stavracas Neto's avatar
      window-actor: Turn into a derivable class · 60f7ff3a
      Georges Basile Stavracas Neto authored
      We will introduce specialized MetaWindowActors for X11
      and Wayland in the future, so it needs to be derivable.
      Make it a derivable class, and introduce a private field.
      The MetaWindowActorClass definition is in the private
      header in order to prevent external consumers of Mutter
      to create MetaWindowActor implementations of their own.
      That is, MetaWindowActor is only internally derivable.
  4. 03 Jan, 2019 12 commits
  5. 02 Jan, 2019 1 commit
    • Daniel Stone's avatar
      gpu/kms: Use correct DRM event context version · 177d0c2d
      Daniel Stone authored
      DRM_EVENT_CONTEXT_VERSION is the latest context version supported by
      whatever version of libdrm is present. Mutter was blindly asserting it
      supported whatever version that may be, even if it actually didn't.
      With libdrm 2.4.78, setting a higher context version than 2 will attempt
      to call the page_flip_handler2 vfunc if it was non-NULL, which being a
      random chunk of stack memory, it might well have been.
      Set the version as 2, which should be bumped only with the appropriate
      version checks.
  6. 22 Dec, 2018 1 commit
    • Jonas Ådahl's avatar
      build: Always pass --quiet to g-ir-scanner · f7d4a727
      Jonas Ådahl authored
      This makes the build less verbose, as all .gir generation except for
      clutters didn't pass --quiet to g-ir-scanner, making it output long
      linking commands. Do this by adding a common introspection_args
      While at it, put -U_GNU_SOURCE in there too, as it was always passed
      everywhere as without it the scanner would log warnings.
  7. 21 Dec, 2018 2 commits
  8. 20 Dec, 2018 5 commits
    • Georges Basile Stavracas Neto's avatar
      meson: Print some configure flags · 7a75692e
      Georges Basile Stavracas Neto authored
      Just an additional touch after adding installed tests,
      outputting those flags helped not losing track of them.
    • Georges Basile Stavracas Neto's avatar
      meta/tests: Remove commented lines · 9bd427a7
      Georges Basile Stavracas Neto authored
      Leftovers from the initial landing of Meson files.
    • Georges Basile Stavracas Neto's avatar
      Add Meson support for installed tests · ebb6c56f
      Georges Basile Stavracas Neto authored
      This is the last remaining feature necessary to achieve
      parity with the Autotools build.
      A few changes were made to the install locations of the
      tests, in order to better acomodate them in Meson:
       * Tests are now installed under a versioned folder (e.g.
       * The mutter-cogl.test file is now generated from an .in
         file, instead of a series of $(echo)s from within Makefile.
      Notice that those tests need very controlled environments
      to run correctly. Mutter installed tests, for example, will
      failed when running under a regular session due to D-Bus
      failing to acquire the ScreenCast and/or RemoteScreen names.
    • Georges Basile Stavracas Neto's avatar
      build: Move libmutter_name to toplevel Meson file · dcb52539
      Georges Basile Stavracas Neto authored
      The libmutter name will be reused by other Meson files,
      so it makes sense to share it instead of rebuilding this
      string every time.
    • Georges Basile Stavracas Neto's avatar
      cogl/tests: Use tmp file to dump test results · 05ab8eeb
      Georges Basile Stavracas Neto authored
      When running installed tests, the working directory for Cogl
      tests is /usr/libexec/installed-tests/mutter-cogl-4/conform,
      which isn't writable by normal users.
      To avoid the adding stray hidden files to the current directory,
      adapt the runner script to fallback to $(mktemp) - which is
      available on all platform we care about - and avoid adding
      hidden files everywhere.
  9. 19 Dec, 2018 2 commits
    • Pekka Paalanen's avatar
      cogl: Pick glReadPixels format by target, not source · 981b0454
      Pekka Paalanen authored
      Presumably glReadPixels itself can be more performant with pixel format
      conversions than doing a fix-up conversion on the CPU afterwards. Hence,
      pick required_format based on the destination rather than the source, so
      that it has a better chance to avoid the fix-up conversion.
      With CoglOnscreen objects, CoglFramebuffer::internal_format (the source
      format) is also wrong. It is left to a default value and never set to
      reflect the reality. In other words, read-pixels had an arbitrary
      intermediate pixel format that was used in glReadPixels and then fix-up
      conversion made it work for the destination.
      The render buffers (GBM surface) are allocated as DRM_FORMAT_XRGB8888.
      If the destination buffer is allocated as the same format, the Cogl
      read-pixels first converts with glReadPixels XRGB -> ABGR because of the
      above default format, and then the fix-up conversion does ABGR -> XRGB.
      This case was observed with DisplayLink outputs, where the native
      renderer must use the CPU copy path to fill the "secondary GPU"
      This patch stops using internal_format and uses the desired destination
      format instead.
      _cogl_framebuffer_gl_read_pixels_into_bitmap() will still use
      internal_format to determine alpha premultiplication state and multiply
      or un-multiply as needed. Luckily all the formats involved in the
      DisplayLink use case are always _PRE and so is the default
      internal_format too, so things work in practise.
      Furthermore, the GL texture_swizzle extension can never apply to
      glReadPixels. Not even with FBOs, as found in this discussion:
      Therefore the target_format argument is hardcoded to something that can
      never match anything, which will prevent the swizzle from being assumed.
    • Pekka Paalanen's avatar
      cogl: Remove mesa_46631_slow_read_pixels_workaround · 6502735f
      Pekka Paalanen authored
      This function gets hit even today on relatively modern Intel systems (I
      have a Haswell Desktop with Mesa 18.2.4) if the pixel format is right.
      Presumably it makes things slower for no longer a reason.
      According to cb146dc5, this
      functionality was refactored into a workaround path in 2012. The commit
      message mentions the problem existing before Mesa 8.0.2. The number
      refers to https://bugs.freedesktop.org/show_bug.cgi?id=46631 .
      The use case where I hit this is when improving support for DisplayLink
      video outputs. These are used through a "secondary GPU", and since
      DisplayLink does not have a GPU, Mutter uses the CPU copy path with Cogl
      read-pixels[1]. If the DisplayLink framebuffer was allocated as
      DRM_FORMAT_XRGB8888 (the only format it currently handles correctly),
      mesa_46631_slow_read_pixels_workaround would get hit. The render buffer is
      the same format as the framebuffer, yet doing the copy XRGB -> XRGB ends
      up being slower than XRGB -> XBGR which makes no sense.
      This patch is not sufficient to fix the XRGB -> XRGB copy performance,
      but it is required.
      This patch reverts CoglGpuInfoDriverBug into what it was before
      [1] This is not actually true until
          !278 is