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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
