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
      fb.
      
      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.
      
      !818
      7049b2f2
  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.
      DRM_CAP_DUMB_PREFER_SHADOW).
      
      !807
      437f6b3d
    • 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.
      
      !809
      05e1a6c2
    • 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
      
      !780
      25c1a853
    • 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.
      
      !780
      bba8f6c5
    • 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.
      
      !811
      dbe9daeb
    • 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
      _NET_ACTIVE_WINDOW.
      
      Closes: #819
      8fd55fef
  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
      keys.
      
      #823
      76f2579e
    • 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.
      
      #823
      0706e021
  7. 20 Sep, 2019 16 commits
  8. 16 Sep, 2019 5 commits
  9. 13 Sep, 2019 3 commits
  10. 12 Sep, 2019 3 commits