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

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

[John Stultz]

Just wanted to send this out for some initial review and feedback.

As noted by Arve and others, since wall time can jump backwards, it
is difficult to use for input because one cannot determine if one
event occured before another or for how long a key was pressed.

However, the timestamp field is part of the kernel ABI, and cannot
be changed without possibly breaking existing users.

This patch adds a new IOCTL that sets a flag in the evdev_client
struct that will switch the timestamps to CLOCK_MONOTONIC instead
of CLOCK_REALTIME. This allows users of the evdev to specifiy
which clock id they want the timestamps to use.

The default remains CLOCK_REALTIME.

CC: Dmitry Torokhov <dmitry.torokhov@gmail.com>
CC: Daniel Kurtz <djkurtz@google.com>
CC: linux-input@vger.kernel.org
CC: Arve Hjønnevåg <arve@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
---
 drivers/input/evdev.c |   30 ++++++++++++++++++++++++++----
 include/linux/input.h |    2 ++
 2 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 4cf2534..6d04403 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -46,6 +46,7 @@ struct evdev_client {
 	struct fasync_struct *fasync;
 	struct evdev *evdev;
 	struct list_head node;
+	bool use_monotonic;
 	unsigned int bufsize;
 	struct input_event buffer[];
 };
@@ -54,8 +55,19 @@ static struct evdev *evdev_table[EVDEV_MINORS];
 static DEFINE_MUTEX(evdev_table_mutex);
 
 static void evdev_pass_event(struct evdev_client *client,
-			     struct input_event *event)
+			     struct input_event *event,
+			     ktime_t mono, ktime_t real)
 {
+	struct timespec ts;
+
+	if (client->use_monotonic)
+		ts = ktime_to_timespec(mono);
+	else
+		ts = ktime_to_timespec(real);
+	event->time.tv_sec = ts.tv_sec;
+	event->time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
+
+
 	/* Interrupts are disabled, just acquire the lock. */
 	spin_lock(&client->buffer_lock);
 
@@ -94,8 +106,11 @@ static void evdev_event(struct input_handle *handle,
 	struct evdev *evdev = handle->private;
 	struct evdev_client *client;
 	struct input_event event;
+	ktime_t time_mono, time_real;
+
+	time_mono = ktime_get();
+	time_real = ktime_sub(time_mono, ktime_get_monotonic_offset());
 
-	do_gettimeofday(&event.time);
 	event.type = type;
 	event.code = code;
 	event.value = value;
@@ -103,11 +118,12 @@ static void evdev_event(struct input_handle *handle,
 	rcu_read_lock();
 
 	client = rcu_dereference(evdev->grab);
+
 	if (client)
-		evdev_pass_event(client, &event);
+		evdev_pass_event(client, &event, time_mono, time_real);
 	else
 		list_for_each_entry_rcu(client, &evdev->client_list, node)
-			evdev_pass_event(client, &event);
+			evdev_pass_event(client, &event, time_mono, time_real);
 
 	rcu_read_unlock();
 
@@ -683,6 +699,12 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
 		else
 			return evdev_ungrab(evdev, client);
 
+	case EVIOCMONTIME:
+		if (copy_from_user(&i, p, sizeof(unsigned int)))
+			return -EFAULT;
+		client->use_monotonic = i;
+		return 0;
+
 	case EVIOCGKEYCODE:
 		return evdev_handle_get_keycode(dev, p);
 
diff --git a/include/linux/input.h b/include/linux/input.h
index 3862e32..245bfcc 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -129,6 +129,8 @@ struct input_keymap_entry {
 
 #define EVIOCGRAB		_IOW('E', 0x90, int)			/* Grab/Release device */
 
+#define EVIOCMONTIME		_IOW('E', 0xA0, int)			/* Set CLOCK_MONOTONIC Timestamps */
+
 /*
  * Device properties and quirks
  */
-- 
1.7.3.2.146.gca209

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Dmitry Torokhov]

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.

Thanks.

-- 
Dmitry

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

[John Stultz]

On Thu, 2012-01-05 at 15:28 -0800, 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.

That sounds like a good idea. 
Otherwise any conceptual issues with the patch?

Arve: If this is something we can get upstream, do you see any
complications in getting the Android evdev user to use this IOCTL to
change the timestamp mode?

thanks
-john

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

[Chase Douglas]

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?

-- Chase

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

[John Stultz]

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.

thanks
-john

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

[Chase Douglas]

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.

-- Chase

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

[Dmitry Torokhov]

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

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

[Chase Douglas]

On 01/05/2012 04:44 PM, Dmitry Torokhov wrote:
> 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.

I know we've talked about it before, and maybe that's the conclusion we
came to. I can't remember at this point.

Until we actually implement a solution, though, we don't really know if
either way would really work. That's why I suggest leaving our options
open by ensuring we have a way to specify device time through this
mechanism if it's reasonable.

-- Chase