On Wed, Dec 21, 2011 at 10:23 AM, john stultz <johnstul@xxxxxxxxxx> wrote: > On Wed, 2011-12-21 at 10:11 +0800, Daniel Kurtz wrote: >> On Wed, Dec 21, 2011 at 9:41 AM, Wanlong Gao <gaowanlong@xxxxxxxxxxxxxx> wrote: >> > On 12/21/2011 09:01 AM, john stultz wrote: >> > >> >> Hi >> >> In reviewing the Android patch set, I noticed the following patch from >> >> Arve which looks like it resolves a reasonable issue (events using >> >> CLOCK_REALTIME timestamps, which can jump forwards or backwards via >> >> settimeofday()). >> >> >> >> I'm not very familiar with the evdev interface, so I'm not sure if >> >> changing the timestamps to CLOCK_MONOTONIC could cause an ABI problem >> >> with legacy apps. Even so, I wanted to send the patch out for review and >> >> consideration as it seems like a reasonable fix. >> >> Maybe you will have more luck this time. You can read the previous >> thread on this exact topic, here: >> https://lkml.org/lkml/2011/10/3/37 > > Interesting! Thanks for the link! > >> The previous attempt got bogged down when people wanted more data on >> use cases and how this patch would promote world peace. I strongly >> support the concept, but we found other ways to address our major >> concern at the time, so didn't invest more effort to get that patch >> accepted. >> >> Just a question though, why ktime_get_ts() and not getrawmonotonic()? > > So rawmonotonic isn't frequency corrected via NTP, while the monotonic > clock is. So if you're calculating intervals, you will get more accurate > times (where a second is a second) w/ ktime_get_ts(). > > The raw monotonic clock is really only useful for time correction > applications (being able to accurately measure how much of a correction > was applied), or when you really want a abstracted sense of hardware > cycles. And here is where it gets complicated. I think it depends on what you want from your timestamps. Do you care that the actual timestamps are accurate (wrt wall clock = MONOTONIC), or that inter-event timetamp spacing is consistent (MONOTONIC_RAW)? For our use case, we don't really care about the absolute timestamp itself, just relative timestamp differences. We wanted to make sure that the inter-event times were always consistent, and didn't wobble about in response to cock adjustments. The affect of clock skew on timestamp deltas is miniscule. -Dan > > thanks > -john > > > -- > 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 -- 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
