1. 02 May, 2012 3 commits
    • Ander Conselvan de Oliveira's avatar
      compositor-drm: refactor to avoid unnecessary allocation of KMS FBs · 555c17dd
      Ander Conselvan de Oliveira authored
      Currently, the drm backend will create and destroy a KMS FB for each
      frame. However, the bos for a gbm surface are reused (at least with
      mesa) so we can store the fb_id on it and destroy it only on the bo's
      destroy callback.
      To use the same path for scanning out client buffers, some refactor
      was needed. Previously, the bo for the client buffer was destroyed
      early so that gbm_surface_release_buffer() would not be called with
      it, since at the page flip handler output->scanout_buffer can be
      NULL even if the current frame is a client buffer.
      This was solved by adding a drm_fb structure that holds a gbm_bo,
      an fb_id, and information about the fb coming from a client buffer
      or not. A drm_fb is created in such a way that it is destroyed
      whenever the bo it references is destroyed. The fields current_*
      and next_* in drm_output are changed into only two pointers to
    • Kristian H. Kristensen's avatar
    • Kristian H. Kristensen's avatar
  2. 30 Apr, 2012 2 commits
  3. 27 Apr, 2012 8 commits
  4. 26 Apr, 2012 8 commits
  5. 25 Apr, 2012 4 commits
  6. 22 Apr, 2012 5 commits
  7. 20 Apr, 2012 8 commits
  8. 19 Apr, 2012 2 commits