Skip to content
Snippets Groups Projects
  1. Aug 16, 2017
  2. May 23, 2017
  3. Mar 14, 2017
  4. Mar 13, 2017
  5. Jan 17, 2017
  6. Oct 05, 2016
  7. Oct 03, 2016
  8. Jul 26, 2016
  9. Jun 23, 2016
  10. Jun 17, 2016
    • Pekka Paalanen's avatar
      compositor-fbdev: drop EGL support · e77f8ad7
      Pekka Paalanen authored
      
      EGL code was added to the fbdev backend in
      4aa756dc in 2013, apparently for running
      Weston on libhybris with Android hardware drivers.
      
      This actually had nothing to do with the fbdev backend, really. Fbdev
      was just a convenient platform to plug in the EGL init code and load
      GL-renderer. Fbdev itself was not used at all in this case.
      
      Fbdev should be forgotten and die, as we have better interfaces for
      accelerated rendering and for controlling displays. It may be a bit too
      harsh to remove the whole fbdev backend just yet, but let us at least
      simplify it this much.
      
      Fbdev+EGL has been the unholy union used by proprietary driver stacks of
      hardware vendors in the non-PC world as a quick and dirty way to get
      something out on the screen. In these cases it is actually the EGL
      implementation that does everything internally, fbdev is not needed.
      Fbdev was never meant for the sort anyway.
      
      If anyone still needs this use case, I recommend sticking with a
      outdated Weston to match your outdated platform. Or if you really
      insist, write a new backend that does not pretend to use fbdev and just
      initializes EGL and GL-renderer.
      
      Cc: Adrian Negreanu <groleo@gmail.com>
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: default avatarQuentin Glidic <sardemff7+git@sardemff7.net>
      Reviewed-by: default avatarDerek Foreman <derekf@osg.samsung.com>
      e77f8ad7
  11. Jun 06, 2016
  12. Jun 03, 2016
  13. Apr 29, 2016
  14. Mar 07, 2016
  15. Jan 12, 2016
  16. Dec 22, 2015
  17. Dec 18, 2015
  18. Oct 23, 2015
  19. Sep 24, 2015
  20. Sep 10, 2015
  21. Aug 20, 2015
  22. Aug 06, 2015
  23. Jul 17, 2015
  24. Jul 10, 2015
  25. Jul 09, 2015
    • Giulio Camuffo's avatar
      compositor: introduce struct weston_backend · 954f183e
      Giulio Camuffo authored and Pekka Paalanen's avatar Pekka Paalanen committed
      
      This is a preliminary change for libweston, with no functional modifications.
      Separate the backends and the core weston_compositor struct, by creating
      the weston_compositor in the main(), and having the various backends extend
      the weston_backend struct, an instance of which is returned by the backend
      entry point.
      This enable us to logically separate the compositor core from the backend,
      allowing the core to be extended without messing with the backends.
      
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      954f183e
  26. Jun 16, 2015
  27. Jun 15, 2015
  28. May 18, 2015
  29. May 08, 2015
    • Giulio Camuffo's avatar
      compositor: send the output_created signal after inserting it in the list · b114715d
      Giulio Camuffo authored
      The compositor's output_created signal used to be sent in weston_output_init()
      which the backend call before putting the output in the output_list.
      This caused problems when creating a new view in a listener to that signal,
      because weston_view_assign_output() doesn't yet know the new output exists.
      To fix this add a new weston_composito_add_output() func which adds the
      output in the list and later sends the signal, and make the backends call
      that.
      b114715d
  30. Mar 26, 2015
  31. Mar 20, 2015
  32. Mar 18, 2015
  33. Jan 21, 2015
    • 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
  34. Jan 17, 2015
  35. Dec 03, 2014
Loading