Re: [PATCH 0/6] drm: trace: Introduce drm_trace() and instrument drm_atomic.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Nov 08, 2019 at 10:16:59AM +0200, Pekka Paalanen wrote:
> Is it ok to build userspace to rely on these trace events during normal
> operations, e.g. for continuous adjustment of timings/timers?

Aside discussion on this: If we add this (I think userspace might want
some information about the point of no return and why we missed it) then I
think we should expose that with an improved drm_event and clear
semantics.

If we start to encourage compositors to use tracepoints to figure out why
the kernel doesn't behave (TEST_ONLY failure, or missed flip target), and
use that for behaviour, we've baked implementation details into the uapi.
And then we're screwed.

So if you have any need for timing information that you see solved with a
tracepoint, pls bring this up so we can add proper uapi. And yes I know
that if someone doesn't we still need to keep that tracepoint working, but
with all things uapi the question isn't whether we'll screw up (we will),
but how often. And less often is massively better :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux