With triple buffering we might sometimes schedule two swaps and hence
two listeners between consecutive presentation notifications:

 0---------------------------1-----------------------------2----------
  \                             \
   notify0  swap1  post1  swap2  notify1  notify2  post2  ............
                                          ^^^^^^^^^^^^^^

So notify2 happens before it was even posted, with duplicate frame data
from notify1 because they're both fired by the same DRM event. This
mostly seems to happen with multi-monitors, probably because the event
loop is busier and notifications may arrive later. But it could also
happen with a single monitor in theory.

To avoid the problem we move queuing of listeners from swap time to post
time so now everything happens in the right order:

 0---------------------------1-----------------------------2----------
  \                             \                             \
   notify0  swap1  post1  swap2  notify1  post2  ............  notify2
                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^