This fixes the compilation when we have sysprofd fully disabled.
That is not an ideal configuration, but keeping it working
ensures that some of the code is easy copy/paste'able in the
future for some situations.
Re-opening the FD on every poll is pretty expensive. So we should avoid
doing that as well re-use the read buffer (page-aligned, <=1 page) for
the sample data.
The point of this file was to be easily usable by applications that want
to generate capture files (or proxy them). The intention here is that we
only have SpCaptureReader/SpCaptureWriter (and associated bits necessary
to support that).
This makes sure that we do not use GObject from the libsysprof-capture-2.a
while still having GType's in the libsysprof-2.so dynamic library.
We also invert the GObject macro check so that the default is to not
register a GType which increases the chances that copy/paste code does
not run into double-registering a GType if used with an application that
links against libsysprof-2. (One such example could be if Gtk uses this
code for timers, as it would break Sysprof itself).
This reveals that we've got really bogus times from these events. I
think there are two things here: the begin is the submit time, not the
submit-to-hardware time. And the end time is retire, which is too
delayed to be really useful. We need to move i915 over to the
low-level tracepoints.
However, this code proved to be useful for vc4, where I have good
timings.
Max uint was more than we allow, since we steal the top 8 bits for some
other data. This instead checks for 24-bit and warns if the user tries to
store a counter value that was not registered.
We have an annoying issue where we look at all fiends of a counter values
chunk in the counter set frame. So we need those values set to zero. If
we are passed fewer counter values than can fit in the frame, we leave
some of that data uninitialized. This ensures that it is cleared.
This will help make sense of vblank events in a multi-screen
environment (where there are two streams of vblanks), and hopefully
also useful for correlating to compositor events.
The goal here is to avoid having to hard code what visualizers are shown
from the .ui files. We just should add things that we find are supported.
Long term, I think we'll add a concept of an "instrument" which is the
combination of a data source (SpSource) and a visualizer (SpVisualizerRow).
The other goal here is to enable the future support for discovering marks
and adding rows for each of those threads.
