All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chase Douglas <chasedouglas@gmail.com>
To: Henrik Rydberg <rydberg@euromail.se>
Cc: Daniel Kurtz <djkurtz@chromium.org>,
	dmitry.torokhov@gmail.com, linux-input@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Input: evdev - use monotonic clock for event timestamps
Date: Wed, 05 Oct 2011 15:35:11 +0100	[thread overview]
Message-ID: <4E8C6B1F.4090904@gmail.com> (raw)
In-Reply-To: <20111005092341.GB6840@polaris.bitmath.org>

On 10/05/2011 10:23 AM, Henrik Rydberg wrote:
>> I understand your concern about breaking random drivers, and am hoping
>> that someon on this list could indicate whether this is a real concern
>> or not.  To get a better feeling for possible regressions, I checked
>> xf86-input-evdev & -synaptics, and neither uses the evdev timestamp in
>> their current incarnations.  Any idea what else might be a good place
>> to check?
> 
> The input system is used for all sorts of events - switches, for
> instance. The point is that it is nearly impossible to know if
> something will break or not, hence the reluctance to modify interfaces.
> 
>> One option is to make the evdev timestamp clock source a per-driver
>> configuration option (controllable from userspace?).  This sounds like
>> it is doable, but would be significantly more complicated.
>>
>> Another option would be to timestamp with monotonicraw + boottime +
>> sleeptime.  This would be approximately wall clock time, but without
>> ntp and slew adjustments.  But, I fear this would just make the rare
>> driver issue less obvious, since it would only become obvious when the
>> two clock sources started drifting apart.
> 
> I agree, the problem is not really solvable. Dmitry?

We could put it into the -next tree early on in the cycle, and then it
will be in -next for a cycle and in Linus' tree for the real dev cycle.
By that time we would hope any issues would have emerged.

I'm not sure if that is a responsible approach. I agree that the change
would be good, but how sure would we be that nothing would break based
only on testing in development trees?

My personal thoughts are that I doubt it would cause issues. Based on
that gut feel, I would say that this approach is reasonable. However,
I'm just one voice in all this :).

-- Chase

  reply	other threads:[~2011-10-05 14:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-03  6:43 [PATCH] Input: evdev - use monotonic clock for event timestamps Daniel Kurtz
2011-10-03  9:06 ` Henrik Rydberg
2011-10-05  7:55   ` Daniel Kurtz
2011-10-05  7:55     ` Daniel Kurtz
2011-10-05  9:23     ` Henrik Rydberg
2011-10-05 14:35       ` Chase Douglas [this message]
2011-10-06  3:42         ` Dmitry Torokhov
2011-10-06  6:25           ` Daniel Kurtz
2011-10-07  6:36             ` Dmitry Torokhov
2011-10-07  6:36               ` Dmitry Torokhov
2011-10-07 11:05               ` Henrik Rydberg

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=4E8C6B1F.4090904@gmail.com \
    --to=chasedouglas@gmail.com \
    --cc=djkurtz@chromium.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rydberg@euromail.se \
    /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.