1. 26 Jul, 2016 1 commit
  2. 23 Jun, 2016 1 commit
  3. 15 Jun, 2015 1 commit
  4. 19 Jun, 2014 1 commit
    • Jonny Lamb's avatar
      animation: ensure repaints are always scheduled during animations · f8bfd058
      Jonny Lamb authored
      Animations are run off the repaint cycle so if there's nothing to
      repaint, an animation will stop running. This is usually not a problem
      as each frame function of an animation causes something to change and
      therefore a repaint to happen. This patch helps detect when the
      animation isn't in said case and triggers a repaint to keep the
      animation running.
      
      This problem was found by using weston_move_scale_run() to move a view
      onscreen from completely off. The very first time the animation frame
      function was called the progress wasn't enough to move it into
      view. The compositor saw there was nothing to repaint and stopped
      doing anything else. When something else (like a pointer move) forced
      a redraw, the view's position was very much onscreen and jumped into
      view in an ugly way.
      f8bfd058
  5. 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>
      a7af7043
  6. 16 Aug, 2013 1 commit
  7. 17 Jun, 2013 2 commits
  8. 05 Jun, 2013 4 commits
  9. 18 Feb, 2013 2 commits
  10. 06 Apr, 2012 1 commit
    • Benjamin Franzke's avatar
      Introduce weston-launch · bfeda130
      Benjamin Franzke authored
      weston-launch starts weston and provides mechanism
      for weston to set/drop drm master, open a tty,
      and read input devices without being root.
      
      Execution is allowed for local-active sessions
      or users in the group weston-launch.
      bfeda130
  11. 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
      compositor.
      8334bc1e
  12. 18 Dec, 2011 1 commit