Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751675AbdIOSeV (ORCPT ); Fri, 15 Sep 2017 14:34:21 -0400 Received: from mail-ua0-f196.google.com ([209.85.217.196]:33382 "EHLO mail-ua0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751631AbdIOSeT (ORCPT ); Fri, 15 Sep 2017 14:34:19 -0400 X-Google-Smtp-Source: AOwi7QB9/VCFmhG++RCl6MGrZAodFSGl6jTjd257Uws4lD5b5qwbpja3uTocWAx5DEDRf3odYbG/YgHGiRE28wyieLY= MIME-Version: 1.0 In-Reply-To: <20170914205804.GA24339@amd> References: <20170913175400.42744-1-dtwlin@google.com> <20170913202032.GA30844@amd> <9c75c3a9-4123-c7f3-7725-45ba752d672a@gmail.com> <20170914205804.GA24339@amd> From: Dmitry Torokhov Date: Fri, 15 Sep 2017 11:34:16 -0700 Message-ID: Subject: Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer To: Pavel Machek Cc: Jacek Anaszewski , "linux-input@vger.kernel.org" , David Lin , Jonathan Corbet , Richard Purdie , Hans de Goede , Greg Kroah-Hartman , Rob Herring , Rom Lemarchand , "linux-doc@vger.kernel.org" , lkml , "linux-leds@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2736 Lines: 66 On Thu, Sep 14, 2017 at 1:58 PM, Pavel Machek wrote: > On Thu 2017-09-14 21:31:31, Jacek Anaszewski wrote: >> Hi David and Pavel, >> >> On 09/13/2017 10:20 PM, Pavel Machek wrote: >> > Hi! >> > >> >> These patch series add the LED_BRIGHTNESS_FAST flag support for >> >> ledtrig-transient to use hrtimer so that platforms with high-resolution timer >> >> support can have better accuracy in the trigger duration timing. The need for >> >> this support is driven by the fact that Android has removed the timed_ouput [1] >> >> and is now using led-trigger for handling vibrator control which requires the >> >> timer to be accurate up to a millisecond. However, this flag support would also >> >> allow hrtimer to co-exist with the ktimer without causing warning to the >> >> existing drivers [2]. >> > >> > NAK. >> > >> > LEDs do not need extra overhead, and vibrator control should not go >> > through LED subsystem. >> > >> > Input subsystem includes support for vibrations and force >> > feedback. Please use that instead. >> >> I think that most vital criterion here is the usability of the >> interface. If it can be harnessed for doing the work seemingly >> unrelated to the primary subsystem's purpose, that's fine. >> Moreover, it is extremely easy to use in comparison to the force >> feedback one. > > Well, no. > > Kernel is supposed to provide hardware abstraction, that means it > should hide differences between different devices. > > And we already have devices using input as designed. We don't want to > have situation where "on phones A, D and E, vibrations are handled via > input, while on B, C and F, they are handled via /sys/class/leds". > > If we want to have discussion "how to make vibrations in input > easier to use", well that's fair. But I don't think it is particulary hard. > I would like to know more about why you find the FF interface hard, given that for rumble you need calls - one ioctl to set up rumble parameters, and a write to start the playback. The FF core should take care of handling duration of the effect, ramping it up and decaying, if desired, and we make sure to automatically stop effects when userspace closes the fd (because of ordinary exit or crash or FD being revoked). > If we want to say "lets move all vibrations from input to LED > subsystem"... I don't think that is good idea, but its a valid > discussion. Some good reasons would be needed. > > But having half devices use one interface and half use different one > is just bad... Completely agree here. I just merged PWM vibra driver from Sebastian Reichel, we already had regulator-haptic driver, do we need gpio-based one? Or make regulator-based one working with fixed regulators? Thanks. -- Dmitry