Hi! > >> 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, > > led-transient trigger can be activated using only following bash > commands: > > # echo 1 > state > # echo 1000 > duration > # while [ 1 ]; do echo 1 > activate; sleep 3; done > > Could you share sample sequence of commands to use ff driver? Well, LED transient trigger can be activated like that. But that will not work on any hardware currently supported by the mainline kernel. Equivalent command with forcefeedback is: (echo 5; sleep 1; echo -1) | sudo fftest /dev/input/event2 You would not want to use either in production. > >> 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? > > Just to clarify: the background of this discussion is the question > whether we should remove the following lines from > Documentation/leds/ledtrig-transient.txt: > > -As a specific example of this use-case, let's look at vibrate feature on > -phones. Vibrate function on phones is implemented using PWM pins on SoC or > -PMIC. There is a need to activate one shot timer to control the vibrate > -feature, to prevent user space crashes leaving the phone in vibrate mode > -permanently causing the battery to drain. > whether we should remove the following use case example from > > In effect Pavel has objections to increasing ledtrig-transient > interval accuracy by adding hr_timer support to it, because vibrate > devices, as one of the use cases, can benefit from it. > > So there are two issues: > 1. Addition of hr_timer support to LED trigger. > 2. Removal of vibrate devices use case from ledtrig-transient doc. > > I am in favour of 1. and against 2. since we're not gaining anything > by hiding information about some kernel functionality when it will > still be there. It also doesn't define the location of any vibrate > device drivers, since sheer leds-gpio driver can be used for that > purpose. I would like to see reasonable explanation why we want 1. (and vibrations are not that) and certainly 2. because we don't want people to use LED subsystem for vibrations. We already have perfectly good interface for that. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
