1. 06 Aug, 2021 2 commits
    • Daniel van Vugt's avatar
      onscreen/native: Post cursor-only updates without awaiting vsync · 410e6ca4
      Daniel van Vugt authored
      This was already true for non-atomic KMS and X11 so it brings
      atomic KMS in line with them.
      There are also performance benefits:
        * The next frame rendered after one or more cursor-only updates gets
          dispatched almost one frame interval sooner, so latency is
          potentially reduced.
        * Triple buffering implementations won't get deceived by the
          outstanding presentation notification and think the GPU is busy.
          It's only the CRTC that's busy. So we can drop back to double
          buffering more reliably now.
      BUG: FIXME: Overqueuing somewhere now, resulting in occasional EBUSY and
                  a black flash.
    • Daniel van Vugt's avatar
  2. 05 Aug, 2021 1 commit
  3. 04 Aug, 2021 15 commits
  4. 02 Aug, 2021 3 commits
  5. 29 Jul, 2021 15 commits
  6. 28 Jul, 2021 2 commits
    • Pascal Nowack's avatar
      core/selection: Cancel selection transfer requests after a timeout · 537e2dfa
      Pascal Nowack authored
      When a selection owner advertises a mime type, but does not provide the
      content upon a request for the mime type content, the requesting side
      might wait indefinitely on the content.
      To avoid this situation, add a timeout source, which will cancel the
      selection transfer request after a certain timeout (15 seconds) passed.
      Part-of: <!1874>
    • Pascal Nowack's avatar
      remote-desktop: Check pipe fd before assuming existing read() operation · 20db6af4
      Pascal Nowack authored
      Currently, if g-r-d closes the read end of the pipe for a
      SelectionRead() operation, due to realizing that the application, that
      should provide the mime type content, does not provide any content,
      mutter won't notice that and still assumes that the read() operation
      on the pipe in g-r-d is still happening, as mutter never writes to the
      pipe in that situation and therefore cannot realize that the pipe is
      already closed.
      The effect of this is, that if g-r-d aborts a read() operation and
      requests a new read() operation via SelectionRead(), mutter will deny
      the request since it assumes that the previous read() operation is
      still ongoing.
      Fix this behaviour by also checking the pipe fd in mutter before
      denying a SelectionRead() request.
      Part-of: <!1874>
  7. 27 Jul, 2021 1 commit
  8. 26 Jul, 2021 1 commit