From: Chase Douglas <chase.douglas@canonical.com>
To: John Stultz <john.stultz@linaro.org>
Cc: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
linux-input@vger.kernel.org, "Daniel Kurtz" <djkurtz@google.com>,
"Arve Hjønnevåg" <arve@android.com>
Subject: Re: [RFC][PATCH] Input: Add infrastrucutre for monotonic event time stamps.
Date: Thu, 05 Jan 2012 16:37:00 -0800 [thread overview]
Message-ID: <4F06422C.2060601@canonical.com> (raw)
In-Reply-To: <1325809186.2290.84.camel@work-vm>
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
next prev parent reply other threads:[~2012-01-06 0:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-05 23:01 [RFC][PATCH] Input: Add infrastrucutre for monotonic event time stamps John Stultz
2012-01-05 23:28 ` Dmitry Torokhov
2012-01-05 23:51 ` John Stultz
2012-01-05 23:54 ` Chase Douglas
2012-01-06 0:19 ` John Stultz
2012-01-06 0:37 ` Chase Douglas [this message]
2012-01-06 0:44 ` Dmitry Torokhov
2012-01-06 0:52 ` Chase Douglas
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=4F06422C.2060601@canonical.com \
--to=chase.douglas@canonical.com \
--cc=arve@android.com \
--cc=djkurtz@google.com \
--cc=dmitry.torokhov@gmail.com \
--cc=john.stultz@linaro.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).