It is possible for vblank events to run out of order with respect to one another because the event which was queued to the kernel has the privilege of running before all other events are handled. This allows kernel-queued events to run before other, older events which should've run first. Although this isn't a huge problem now, it will become more problematic after the next change which ties DRI client notifications to TearFree page flips. This increases the likelihood of DRI clients erroneously receiving presentation-completion notifications out of order; i.e., a client could receive a notification for a newer pixmap it submitted *before* receiving a notification for an older pixmap. Ensure vblank events always run in sequential order by removing the bias towards kernel-queued events, and therefore forcing them to run at their sequential position in the queue like other events. Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Reviewed-by: Martin Roukala <martin.roukala@mupuf.org> |
||
|---|---|---|
| .. | ||
| kdrive | ||
| vfb | ||
| xfree86 | ||
| xnest | ||
| xquartz | ||
| xwayland | ||
| xwin | ||
| meson.build | ||