On 01/05/2012 04:44 PM, Dmitry Torokhov wrote:

On Thu, Jan 05, 2012 at 04:37:00PM -0800, Chase Douglas wrote:

quoted

On 01/05/2012 04:19 PM, John Stultz wrote:

quoted

On Thu, 2012-01-05 at 15:54 -0800, Chase Douglas wrote:

quoted

On 01/05/2012 03:28 PM, Dmitry Torokhov wrote:

quoted

Hi John,

On Thu, Jan 05, 2012 at 03:01:05PM -0800, John Stultz wrote:

quoted

 
+	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