Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751309AbdIRW30 (ORCPT ); Mon, 18 Sep 2017 18:29:26 -0400 Received: from mail-ua0-f195.google.com ([209.85.217.195]:37076 "EHLO mail-ua0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750714AbdIRW3Y (ORCPT ); Mon, 18 Sep 2017 18:29:24 -0400 X-Google-Smtp-Source: ADKCNb50q8Yx4Le4t7W/nbeP6HReKs49/nQJnoABxmSpczojQ1yBQwYJ3JcOySYg6g5f2vrijWAfjem71K8R/d3MhPg= MIME-Version: 1.0 In-Reply-To: <9d5d045e-5019-e132-9449-7fb40b1b7895@gmail.com> References: <20170913175400.42744-1-dtwlin@google.com> <20170913202032.GA30844@amd> <9c75c3a9-4123-c7f3-7725-45ba752d672a@gmail.com> <20170914205804.GA24339@amd> <7a611993-ebaa-08bb-b10c-ebe4fb9ca33a@gmail.com> <0076adca-f843-f99f-09ce-b9839b3e7706@gmail.com> <20170917182251.GA15328@amd> <9d5d045e-5019-e132-9449-7fb40b1b7895@gmail.com> From: Dmitry Torokhov Date: Mon, 18 Sep 2017 15:29:22 -0700 Message-ID: Subject: Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer To: Jacek Anaszewski Cc: Pavel Machek , "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: 3740 Lines: 88 On Mon, Sep 18, 2017 at 1:50 PM, Jacek Anaszewski wrote: > Hi, > > On 09/17/2017 08:22 PM, Pavel Machek wrote: >> Hi! >> >>>> If your objection is that FF is not easily engaged from the shell - >>>> yes, but I do not think that actual users who want to do vibration do >>>> that via shell either. On the other hand, can you drop privileges and >>>> still allow a certain process control your vibrator via LED interface? >>>> With FF you can pass an FD to whoever you deem worthy and later revoke >>>> access. >>>> >>>> IOW sysfs interfaces are nice for quick hacks, but when you want to >>>> use them in real frameworks, where you need to think about proper >>>> namespaces, isolation, etc, etc, other kinds of interfaces might suit >>>> better. >>> >>> I'd leave the decision to the user. We could add a note to the >>> Documentation/leds/ledtrig-transient.txt that force feedback interface >>> should be preferable choice for driving vibrate devices. >> >> We don't want to leave decision to the user; because then we'll end up >> with userland applications having to support _both_ interfaces. > > This state has lasted for five years now. I don't recall any > complaints. Do you? I was telling Shuah 5 years ago that using LED for what she wanted was not the right idea. I even made a patch for her implementing the functionality they were after: https://lkml.org/lkml/2012/4/10/41 Unfortunately this still somehow made it into the kernel. I guess the angle of having LEDs auto-shutoff makes sense still; using it for haptics does not. > >> Plus, it is not really your decision. Dmitry is maintainer of input >> subsystem, input was doing force feedback for 10+ years, and he >> already made a decision. > > It seems that you applied a fait accompli method here. > > Actually could you share what the decision is? AFAIK we're not > discussing here any patch for the input subsystem? No, we are discussing if it makes sense encouraging 2nd interface for haptic. We are also discussing whether it makes sense to implement new features in LED subsystem that seem to be only beneficial for this interface (I assume the "normal" LEDs do not need that kind of precision?). > >>> However only if following conditions are met: >>> - force feedback driver supports gpio driven devices >>> - there is sample application in tools/input showing how to >>> setup gpio driven vibrate device with use of ff interface >>> - it will be possible to setup vibrate interval with 1ms accuracy, >>> similarly to what the discussed patch allows to do >> >> I agree these would be nice. Interested parties are welcome to help >> there. But I don't think this should have any impact on LED >> susbystem. Force feedback just does not belong to LED subsystem. > > You cut off important piece of my text from the beginning of this > paragraph. It was: > >> I'd leave the decision to the user. We could add a note to the >> Documentation/leds/ledtrig-transient.txt that force feedback interface >> should be preferable choice for driving vibrate devices. >> However only if following conditions are met: > > What I meant is that it is my decision, as a LED subsystem maintainer, > to accept the addition of a note about some other subsystem offering > an equivalent or even better substitute of the feature being available > in the subsystem I am responsible for. And I will accept such a patch > only if mentioned conditions are met. Having the wording in documentation does not in any way stops Android folks from continuing [ab]using the transient trigger. But this is their choice. The purpose of documentation is to document the best practices, not all possible crazy solutions one can come up with. Thanks. -- Dmitry