In its original call location, this diagnostic/warning function gets
called for each composition cycle even for client frames which have
not yet been delivered for display, because the frames target display
time "XrFrameEndInfo frameEndInfo.displayTime" (as provided by the
OpenXR client) has not been reached yet. Iow. if a OpenXR client
specifies a target frameEndInfo.displayTime in the future, to request
frame presentation in the future, this will cause a flood of false
"Frame late ..." messages by the compositor, despite nothing being
wrong with the timing, until the frame is actually delivered.
E.g., if frameEndInfo.displayTime is 1 second in the future, we'll
get this for each client xrEndFrame() invocation:
WARN [log_frame_time_diff] Frame late by 11.11ms!
WARN [log_frame_time_diff] Frame late by 22.22ms!
... another 87 like these ...
WARN [log_frame_time_diff] Frame late by 988.43ms!
I think what we want is to only check client frames that are actually
delivered the first time by multi_compositor_deliver_any_frames() for
initial display in the current compositor work cycle, and then report
if this first frame display onset was not on or close to the OpenXR
client requested frameEndInfo.displayTime, but too early or too late,
in violation of the clients wishes.
Moving the call check and call of log_frame_time_diff() achieves this
and gives meaningful debug output.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
This allows to use the metrics logging in "streaming mode" where
records are written out with low delay, e.g., into a Unix fifo
file / pipe for live consumption by some tracing or recording
application.
XRT_METRICS_EARLY_FLUSH=true enables this "streaming mode".
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Does not do anything yet within Monado, but documents how to parse
button state of left headphone volume up/down buttons and right
headphone microphone mute button.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
