From: john stultz <johnstul@us.ibm.com>
To: Daniel Kurtz <djkurtz@google.com>
Cc: gaowanlong@cn.fujitsu.com, linux-input@vger.kernel.org,
"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
"Arve Hjønnevåg" <arve@android.com>
Subject: Re: [RFC][PATCH] Input: Use monotonic time for event time stamps.
Date: Tue, 20 Dec 2011 18:23:31 -0800 [thread overview]
Message-ID: <1324434211.30527.100.camel@work-vm> (raw)
In-Reply-To: <CAGS+omABqM84X=uoY1bGnAD-9DSR6qjrod8Teksm3qeiG2YGew@mail.gmail.com>
On Wed, 2011-12-21 at 10:11 +0800, Daniel Kurtz wrote:
> On Wed, Dec 21, 2011 at 9:41 AM, Wanlong Gao <gaowanlong@cn.fujitsu.com> 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.
thanks
-john
next prev parent reply other threads:[~2011-12-21 2:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-21 1:01 [RFC][PATCH] Input: Use monotonic time for event time stamps john stultz
2011-12-21 1:41 ` Wanlong Gao
2011-12-21 2:11 ` Daniel Kurtz
2011-12-21 2:23 ` john stultz [this message]
2011-12-21 3:34 ` Daniel Kurtz
2011-12-21 7:53 ` john stultz
2011-12-21 8:54 ` Daniel Kurtz
2011-12-21 2:29 ` john stultz
2011-12-21 3:23 ` Daniel Kurtz
2011-12-21 3:12 ` john stultz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1324434211.30527.100.camel@work-vm \
--to=johnstul@us.ibm.com \
--cc=arve@android.com \
--cc=djkurtz@google.com \
--cc=dmitry.torokhov@gmail.com \
--cc=gaowanlong@cn.fujitsu.com \
--cc=linux-input@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.