1. 30 Sep, 2019 1 commit
    • Jonas Ådahl's avatar
      Revert "renderer-native: Actually use shadow fb when using software rendering" · 7049b2f2
      Jonas Ådahl authored
      It was not the lack of forcing the shadow fb that caused slowness, but
      rather due to the method the shadow fb content was copied onto the
      scanout fb. With 'clutter: Use cogl_blit_framebuffer() for shadow FB'
      we'll use a path that shouldn't be slow when copying onto the scanout
      Also 437f6b3d accidentally enabled
      shadow fb when using hw accelerated contexts, due to the cap being set
      to 1 in majority of drivers. While the kernel documentation for the
      related field says "hint to userspace to prefer shadow-fb rendering",
      the name of the hint when exposed to userspace is
      DRM_CAP_DUMB_PREFER_SHADOW, thus should only be taken into consideration
      for dumb buffers, not rendering in general.
      This reverts commit 437f6b3d.
  2. 28 Sep, 2019 1 commit
  3. 27 Sep, 2019 6 commits
    • Jonas Ådahl's avatar
      renderer-native: Actually use shadow fb when using software rendering · 437f6b3d
      Jonas Ådahl authored
      The commit 'renderer/native: Use shadow fb on software GL if preferred'
      attempted to force using a shadow fb when using llvmpipe in order to
      speed up blending, but instead only did so when llvmpipe AND the drm
      device explicityl asked for it.
      Now instead always force it for llvmpipe and other software rendering
      backends, and otherwise just query the drm device (i.e.
    • Olivier Fourdan's avatar
      clutter/stage-view: Use cogl_blit_framebuffer() for shadow FB · 05e1a6c2
      Olivier Fourdan authored
      If there is no transformation, use `cogl_blit_framebuffer()` as a
      shortcut in `clutter_stage_view_blit_offscreen()`, that dramatically
      improves performance when using a shadow framebuffer.
    • Robert Mader's avatar
      wayland/dnd-surface: Scale DnD-surface-actor content if necessary · 25c1a853
      Robert Mader authored
      Since the recent clutter-content work, legacy scaling (in contrast
      to the new stage-view-scaling) only applies to surfaces that belong
      to a window. This broke scaling of DnD surfaces.
      As a workaround, apply the same scaling on DnD-surface-actors until
      we use stage-view-scaling by default and can remove this again.
      Also: small corrections of geometry calculation
    • Robert Mader's avatar
      wayland/actor-surface: Turn get_geometry_scale() into a vfunc · bba8f6c5
      Robert Mader authored
      This allows us to implement more sophisticated logic for the different
      cases. For DnD surfaces, use the geometry scale of the monitor where
      the pointer is, instead of incorrectly assuming '1' as it was before.
    • Jonas Ådahl's avatar
      main: Make process PR_SET_DUMPABLE · dbe9daeb
      Jonas Ådahl authored
      Otherwise we won't get core dumps if the launching binary has
      capabilities set.
    • Carlos Garnacho's avatar
      x11: Update focus on the X11 display before the MetaDisplay · 8fd55fef
      Carlos Garnacho authored
      The meta_display_update_focus_window() call has indirect dependencies
      on the X11 focus window, in order to determine the correct focus window
      on the Wayland side (i.e. may turn out NULL with certain X windows).
      In order to have the right x11_display->focus_xwindow there, we should
      perform first the focus update on the X11 display.
      Fixes focusing of Java applications, as those don't seem to go through
      Closes: #819
  4. 26 Sep, 2019 2 commits
  5. 25 Sep, 2019 1 commit
  6. 24 Sep, 2019 2 commits
    • Olivier Fourdan's avatar
      keybinding: Check for handler functions as well · 76f2579e
      Olivier Fourdan authored
      With the addition of the locate-pointer special keybinding (defaults to
      the [Control] key), we have now two separate special modifier keys which
      can be triggered separately, one for the locate-pointer action and
      another one for overlay.
      When processing those special modifier keys, mutter must ensure that the
      key was pressed alone, being a modifier, the key could otherwise be part
      of another key combo.
      As result, if both special modifiers keys are pressed simultaneously,
      mutter will try to trigger the function for the second key being
      pressed, and since those special modifier keys have no default handler
      function set, that will crash mutter.
      Check if the handler has a function associated and treat the keybinding
      as not found if no handler function is set, as with the special modifier
    • Olivier Fourdan's avatar
      keybindings: Check for a handler before using it · 0706e021
      Olivier Fourdan authored
      The `process_event()` would check for a existing keybinding handler and
      abort if there is none, however the test is done after the handler had
      been accessed, hence defeating the purpose of the check.
      Move the check to verify there is an existing keybinding handler before
      actually using it.
  7. 20 Sep, 2019 16 commits
  8. 16 Sep, 2019 5 commits
  9. 13 Sep, 2019 3 commits
  10. 12 Sep, 2019 3 commits