1. 06 Feb, 2019 1 commit
  2. 17 Jan, 2017 2 commits
  3. 23 Jun, 2016 1 commit
  4. 16 Jun, 2015 1 commit
  5. 15 Jun, 2015 1 commit
  6. 28 Nov, 2014 2 commits
  7. 03 Dec, 2013 1 commit
    • Jason Ekstrand's avatar
      Remove the weston_view.geometry.width/height fields · 918f2dd4
      Jason Ekstrand authored
      This has a couple of additional implications for the internal weston API:
       1) weston_view_configure no longer exists.  Use weston_view_set_position
       2) The weston_surface.configure callback no longer takes a width and
          height.  If you need these, surface.width/height are set before
          configure is called.  If you need to know when the width/height
          changes, you must track that yourself.
  8. 22 Oct, 2013 1 commit
    • Jason Ekstrand's avatar
      Split the geometry information from weston_surface out into weston_view · a7af7043
      Jason Ekstrand authored
      The weston_surface structure is split into two structures:
       * The weston_surface structure storres everything required for a
         client-side or server-side surface.  This includes buffers; callbacks;
         backend private data; input, damage, and opaque regions; and a few other
         bookkeeping bits.
       * The weston_view structure represents an entity in the scenegraph and
         storres all of the geometry information.  This includes clip region,
         alpha, position, and the transformation list as well as all of the
         temporary information derived from the geometry state.  Because a view,
         and not a surface, is a scenegraph element, the view is what is placed
         in layers and planes.
      There are a few things worth noting about the surface/view split:
       1. This is *not* a modification to the protocol.  It is, instead, a
          modification to Weston's internal scenegraph to allow a single surface
          to exist in multiple places at a time.  Clients are completely unaware
          of how many views to a particular surface exist.
       2. A view is considered a direct child of a surface and is destroyed when
          the surface is destroyed.  Because of this, the view.surface pointer is
          always valid and non-null.
       3. The compositor's surface_list is replaced with a view_list.  Due to
          subsurfaces, building the view list is a little more complicated than
          it used to be and involves building a tree of views on the fly whenever
          subsurfaces are used.  However, this means that backends can remain
          completely subsurface-agnostic.
       4. Surfaces and views both keep track of which outputs they are on.
       5. The weston_surface structure now has width and height fields.  These
          are populated when a new buffer is attached before surface.configure
          is called.  This is because there are many surface-based operations
          that really require the width and height and digging through the views
          didn't work well.
      Signed-off-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
  9. 10 Oct, 2013 1 commit
  10. 17 May, 2013 1 commit
  11. 20 Feb, 2013 1 commit
  12. 12 Dec, 2012 1 commit
  13. 04 Oct, 2012 1 commit
  14. 09 Jun, 2012 1 commit
  15. 26 Apr, 2012 1 commit
  16. 17 Apr, 2012 1 commit
    • Pekka Paalanen's avatar
      compositor: move libudev.h to evdev.h · 9bc1a4ef
      Pekka Paalanen authored
      Compositor core does not do anything with udev, so the header is not
      needed there. Move the #include into evdev.h, from where it gets used by
      compositor-drm.c, too.
      Also fix the fallout:
      tty.c: In function 'tty_create':
      tty.c:143:2: warning: implicit declaration of function 'fstat'
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <ppaalanen@gmail.com>
  17. 09 Apr, 2012 1 commit
  18. 03 Jan, 2012 1 commit
    • Kristian H. Kristensen's avatar
      Rename wayland-compositor to weston · 8334bc1e
      Kristian H. Kristensen authored
      This rename addresses a few problems around the split between core
      Wayland and the wayland-demos repository.
      1) Initially, we had one big repository with protocol code, sample
      compositor and sample clients.  We split that repository to make it
      possible to implement the protocol without pulling in the sample/demo
      code.  At this point, the compositor is more than just a "demo" and
      wayland-demos doesn't send the right message.  The sample compositor
      is a useful, self-contained project in it's own right, and we want to
      move away from the "demos" label.
      2) Another problem is that the wayland-demos compositor is often
      called "the wayland compsitor", but it's really just one possible
      compositor.  Existing X11 compositors are expected to add Wayland
      support and then gradually phase out/modularize the X11 support, for
      example.  Conversely, it's hard to talk about the wayland-demos
      compositor specifically as opposed to, eg, the wayland protocol or a
      wayland compositor in general.
      We are also renaming the repo to weston, and the compositor
      subdirectory to src/, to emphasize that the main "output" is the
  19. 18 Dec, 2011 1 commit