From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chase Douglas Subject: Re: [PATCH] Input: evdev - use monotonic clock for event timestamps Date: Wed, 05 Oct 2011 15:35:11 +0100 Message-ID: <4E8C6B1F.4090904@gmail.com> References: <1317624200-9762-1-git-send-email-djkurtz@chromium.org> <20111003090641.GA5615@polaris.bitmath.org> <20111005092341.GB6840@polaris.bitmath.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ey0-f174.google.com ([209.85.215.174]:46509 "EHLO mail-ey0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934462Ab1JEOfQ (ORCPT ); Wed, 5 Oct 2011 10:35:16 -0400 In-Reply-To: <20111005092341.GB6840@polaris.bitmath.org> Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: Henrik Rydberg Cc: Daniel Kurtz , dmitry.torokhov@gmail.com, linux-input@vger.kernel.org, linux-kernel@vger.kernel.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