1. 21 Jan, 2015 5 commits
    • Pekka Paalanen's avatar
      63495864
    • Pekka Paalanen's avatar
      compositor, drm: set per-surface Presentation feedback flags · bf0e031e
      Pekka Paalanen authored
      
      
      PRESENTATION_FEEDBACK_KIND_ZERO_COPY is a flag that needs to be set for
      each surface separately. Some surfaces may be zero-copy (as defined by
      Presentation feedback) while some are not.
      
      A complication with Weston is that a surface may have multiple views on
      screen. All copies (views) of the surface are required to be zero-copy
      for the ZERO_COPY flag to be set.
      
      Backends set per-view feedback flags during the assing_planes hook, and
      then Weston core collects the flags from all views of a surface.
      
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Tested-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      bf0e031e
    • Pekka Paalanen's avatar
      compositor: set presentation.presented flags · 363aa7bc
      Pekka Paalanen authored
      
      
      Change weston_output_finish_frame() signature so that backends are
      required to set the flags, that will be reported on the Presentation
      'presented' event. This is meant for output-wide feedback flags. Flags
      that vary per wl_surface are subject for the following patch.
      
      All start_repaint_loop functions use the special private flag
      PRESENTATION_FEEDBACK_INVALID to mark, that this call of
      weston_output_finish_frame() cannot trigger the 'presented' event. If it
      does, we now hit an assert, and should then investigate why a fake update
      triggered Presentation feedback.
      
      DRM:
      
      Page flip is always vsync'd, and always gets the completion timestamp
      from the kernel which should correspond well to hardware. Completion is
      triggered by the kernel/hardware.
      
      Vblank handler is only used with the broken planes path, therefore do
      not report VSYNC, because we cannot guarantee all the planes updated at
      the same time. We cannot set the INVALID, because it would abort the
      compositor if the broken planes path was ever used.  This is a hack that
      will get fixed with nuclear pageflip support in the future.
      
      fbdev:
      
      No vsync, update done by copy, no completion event from hardware, and
      completion time is totally fake.
      
      headless:
      
      No real output to update.
      
      RDP:
      
      Guessing that maybe no vsync, fake time, and copy make sense (pixels
      sent over network). Also no event that the pixels have been shown?
      
      RPI:
      
      Presumably Dispmanx updates are vsync'd. We get a completion event from
      the driver, but need to read the clock ourselves, so the completion time
      is somewhat unreliable. Zero-copy flag not implemented though it would
      be theoretically possible with EGL clients (zero-copy is a per-surface
      flag anyway, so in this patch).
      
      Wayland:
      
      No information how the host compositor is doing updates, so make a safe
      guess without assuming vsync or hardware completion event. While we do
      get some timestamp from the host compositor, it is not the completion
      time. Would need to hook to the Presentation extension of the host
      compositor to get more accurate flags.
      
      X11:
      
      No idea about vsync, completion event, or copying. Also the timestamp is
      a fake.
      
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Tested-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Acked-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      363aa7bc
    • Pekka Paalanen's avatar
      protocol: add Presentation feedback flags · 0de22a38
      Pekka Paalanen authored
      Add the missing feedback flags to the Presentation extension protocol
      specification.
      
      These flags are slightly different from the previous RFCv3.1 definition:
      http://lists.freedesktop.org/archives/wayland-devel/2014-March/013598.html
      
      
      
      Now, all compositors are safe to use 0 as the flags if they don't bother
      setting them properly. 0 is the "worst case" with the least guarantees.
      
      The meaning of ZERO_COPY is not exactly the opposite of the old COPY
      flag. ZERO_COPY is more strict, but applies only to that one surface.
      Therefore it can be used to verify a zero-copy video playback pipeline,
      also to a hardware overlay.
      
      There is no longer a flag to clearly indicate if the final presentation
      was done by a copy or a page flip. ZERO_COPY forbids the copy, but VSYNC
      alone does allow copy in case it cannot tear.  It is possible to have
      first a compositing pass, and then another copy into the frontbuffer,
      and still set VSYNC if it cannot tear.  Usually "cannot tear" is too
      hard to guarantee with a copy, so it often implies a page flip.
      
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Tested-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      0de22a38
    • Pekka Paalanen's avatar
      compositor-drm: use drm_output in drm_output_*() func args · 050c1ba7
      Pekka Paalanen authored
      
      
      When a function is named drm_output_FOO(), you'd expect it to take a
      struct drm_output * as an argument. Convert
      drm_output_prepare_scanout_view(), drm_output_prepare_overlay_view(),
      drm_output_prepare_cursor_view() from weston_output to drm_output.
      
      Additionally convert drm_sprite_crtc_supported() from weston_output to
      drm_output.
      
      This change makes drm_assign_planes() to operate on drm_output terms,
      which makes further changes a tiny bit easier.
      
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Tested-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      050c1ba7
  2. 17 Jan, 2015 5 commits
  3. 15 Jan, 2015 3 commits
  4. 08 Jan, 2015 1 commit
  5. 19 Dec, 2014 1 commit
  6. 18 Dec, 2014 1 commit
  7. 16 Dec, 2014 2 commits
  8. 15 Dec, 2014 13 commits
  9. 12 Dec, 2014 3 commits
  10. 11 Dec, 2014 2 commits
  11. 08 Dec, 2014 2 commits
    • Pekka Paalanen's avatar
      compositor: Implement JSON-timeline logging · b502654b
      Pekka Paalanen authored
      Logging is activated and deactivated with the debug key binding 't'.
      When activated, it creates a new log file, where it records the events.
      The log file contains events and detailed object information entries in
      JSON format, and is meant to be parsed in sequence from beginning to the
      end.
      
      The emitted events are mostly related to the output repaint cycle, like
      when repaint begins, is submitted to GPU, and when it completes on a
      vblank. This is recorded per-output. Also some per-surface events are
      recorded, including when surface damage is flushed.
      
      To reduce the log size, events refer to objects like outputs and
      surfaces by id numbers. Detailed object information is emitted only as
      needed: on the first object occurrence, and afterwards only if
      weston_timeline_object::force_refresh asks for it.
      
      The detailed information for surfaces includes the string returned by
      weston_surface::get_label. Therefore it is important to set
      weston_timeline_object::force_refresh = 1 whenever the string would
      change, so that the new details get recorded.
      
      A rudimentary parser and SVG generator can be found at:
      https://github.com/ppaalanen/wesgr
      
      
      
      The timeline logs can answer questions including:
      - How does the compositor repaint cycle work timing-wise?
      - When was the vblank deadline missed?
      - What is the latency from surface commit to showing the new content on
        screen?
      - How long does it take to process the scenegraph?
      
      v2: weston_surface::get_description renamed to get_label.
      v3: reafctor a bit into fprint_quoted_string().
      
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      b502654b
    • Pekka Paalanen's avatar
      compositor: add weston_surface_set_label_func() · 8274d901
      Pekka Paalanen authored and Pekka Paalanen's avatar Pekka Paalanen committed
      
      
      When printing out logs from Weston's actions, mainly for debugging, it
      can be very difficult to identify the different surfaces.  Inspecting
      the configure function pointer is not useful, as the configure functions
      may live in modules.
      
      Add vfunc get_label to weston_surface, which will produce a short,
      human-readable description of the surface, which allows identifying it
      better, rather than just looking at the surface size, for instance.
      
      Set the label function from most parts of Weston, to identify cursors and
      drag icons, and panels, backgrounds, screensavers and lock surfaces, and
      the desktop shell's application surfaces.
      
      v2: renamed 'description' to 'label', so we get
      	weston_surface_set_label_func().
      
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      8274d901
  12. 04 Dec, 2014 2 commits