Re: [PATCH] input: API for Setting a Timestamp from a Driver

[Dmitry Torokhov]

On Fri, Jul 12, 2019 at 09:46:19PM +1000, Peter Hutterer wrote:
> On Fri, Jul 12, 2019 at 09:23:20AM +0200, Benjamin Tissoires wrote:
> > On Fri, Jul 12, 2019 at 8:41 AM Dmitry Torokhov
> > <dmitry.torokhov@xxxxxxxxx> wrote:
> > >
> > > Hi Atif,
> > >
> > > On Wed, Jul 10, 2019 at 04:04:10PM -0700, Atif Niyaz wrote:
> > > > Currently, evdev stamps time with timestamps acquired in
> > > > evdev_events. However, this timestamping may not be accurate in terms of
> > > > measuring when the actual event happened. This API allows any 3rd party
> > > > driver to be able to call input_set_timestamp, and provide a timestamp
> > > > that can be utilized in order to provide a more accurate sense of time
> > > > for the event
> > > >
> > > > Signed-off-by: Atif Niyaz <atifniyaz@xxxxxxxxxx>
> > >
> > > This looks OK to me. Benjamin, Peter, any concerns here?
> > >
> > 
> > No red flags from me (though Peter is the one using all of this).
> > 
> > Just curious, which drivers do you think will be using this new API?
> > I can see that we might want to use hid-multitouch for it, with the
> > Scan Time forwarded by the device, but what do you have in mind?
> 
> that'd be my question as well. I'm all for more precise evdev timestamps but
> there's some overlap with MSC_TIMESTAMP (which at least libinput isn't
> handling well right now, with the exception of some quirk detection). 

I expect it will be used by drivers that use threaded interrupts to mark
the time in the hard interrupt and avoid the latency of scheduling the
thread, slow bus communication, etc.

This is not supposed to replace MSC_TIMESTAMP as MSC_TIMESTAMP carries
timestamp acquired by the device itself.

Thanks.

-- 
Dmitry