PresentIdleNotify events will not be delivered for PresentPixmapSynced
requests. This should be stated explicitly in the protocol specification.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Adds an augmented version of PresentPixmap supporting explicit
synchronization with a direct rendering device. This takes the form of
timeline DRM synchronization objects, along with acquire and release
points on those timelines. Implementations advertising
PresentCapabilitySyncobj will wait for the acquire point to be signaled
before executing the PresentPixmap request, and signal the release point
after any GPU operations on the pixmap have completed.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Bump the presentproto version to 1.3 in the pkg-config file,
presentproto.txt and presenttokens.h.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: 5a3d5d624 - present: add PresentOptionAsyncMayTear
If the Complete event has this mode, the client is not using
the more optimal format/modifier for the buffer allocation. The
client must explicitely inform the server that it understands
this mode by adding the PresentOptionSuboptimal flag when calling
PresentPixmap.
Its main usage as of now is to allow clients to re-fetch DRI3
format modifiers as some modifiers might allow direct scanout.
Bump presentproto version to 1.2.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Pixmaps will definitely be idle after the next PresentPixmap operation
completes; the original text was vague about whether it was the
execution of the request or the completion of the operation.
Signed-off-by: Keith Packard <keithp@keithp.com>
Changes the name of the PresentPixmap request from PresentRegion in
anticipation of future additions of non-pixmap sourced updates (YUV
images in particular).
Adds definitions for all of the new PresentPixmap options.
Adds PresentQueryCapabilities to provide applications the ability to
learn what the underlying hardware can support. One requirement for
any capability is that the X server must do something sensible even if
the client behaves as if a capability is supported when it is not.
Adds IdleNotify events. As pixmaps can go idle in any order, it's
important for applications to know which pixmap to use next. We cannot
use fences as the fence itself may not be signaled for some time after
the X server has figured out which pixmap to idle.
Note that the encoding and header files are not entirely up to date now.
Signed-off-by: Keith Packard <keithp@keithp.com>
In PresentRegion, add the PresentNotify list, add explicit CRTC.
In PresentRedirectNotify, add CRTC and update_window values
Signed-off-by: Keith Packard <keithp@keithp.com>
SBC is entire a client-side notion, so remove it from the protocol.
No need to have two events with the same content, but we do need to
tell which request generated the event so stick a new field in some
spare bytes
Signed-off-by: Keith Packard <keithp@keithp.com>
