Re: [RFC][PATCH] Input: Add infrastrucutre for monotonic event time stamps.

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Thu, Jan 05, 2012 at 04:37:00PM -0800, Chase Douglas wrote:
> On 01/05/2012 04:19 PM, John Stultz wrote:
> > On Thu, 2012-01-05 at 15:54 -0800, Chase Douglas wrote:
> >> On 01/05/2012 03:28 PM, Dmitry Torokhov wrote:
> >>> Hi John,
> >>>
> >>> On Thu, Jan 05, 2012 at 03:01:05PM -0800, John Stultz wrote:
> >>>>  
> >>>> +	case EVIOCMONTIME:
> >>>> +		if (copy_from_user(&i, p, sizeof(unsigned int)))
> >>>> +			return -EFAULT;
> >>>> +		client->use_monotonic = i;
> >>>> +		return 0;
> >>>
> >>> Maybe we should let users pass not boolean but CLOCK_* value (and reject
> >>> ones that we do not support) ? This way if someone wants to use some
> >>> other clock type in the future we won't need new ioctl.
> >>
> >> Could we also find a way to specify device time? Apple's Magic Mouse and
> >> Magic Trackpad spit out events with their own timestamps. Maybe there
> >> would be other devices that would support high accuracy timestamps too?
> > 
> > The dynamic posix clocks stuff already supports this sort of thing for
> > PTP, but its driver by driver, and its not all that clear that you can
> > read the device timestamp any old time you want (I suspect they're all
> > tied to device events). So it won't quite work for a clock_gettime()
> > style usage.
> > 
> > I don't really know what the best way to do this would be. We could
> > overload a negative clockid value, since you're not going to be wanting
> > thread cputime for device timestamps. But that's not super elegant
> > either.
> > 
> > But just having a specified clock id via the ioctl makes something like
> > what you're proposing possible.  Just a matter of how to cleanly specify
> > device timestamps against all the other possible ids.
> 
> I guess this is mostly what I'm after right now. I have no plans on
> implementing device timestamps, and I don't even really have time to
> think about it much right now :). As long as we have a plan for how we
> could specify it in the future, if someone wanted to implement it, then
> I'm happy.
> 

I'd consider device-generated timestamps be similar to the other
elements of input stream, like coordinates, and therefore transmitted
via their own event type, something like EV_MSC/MSC_TIME.

-- 
Dmitry