Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1741198 > unrolled thread
| Started by | David Lin <dtwlin@google.com> |
|---|---|
| First post | 2017-09-28 07:10 +0200 |
| Last post | 2017-09-28 21:30 +0200 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer David Lin <dtwlin@google.com> - 2017-09-28 07:10 +0200
Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-09-28 07:50 +0200
Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer David Lin <dtwlin@google.com> - 2017-09-28 21:30 +0200
| From | David Lin <dtwlin@google.com> |
|---|---|
| Date | 2017-09-28 07:10 +0200 |
| Subject | Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer |
| Message-ID | <uuzfb-4BT-1@gated-at.bofh.it> |
Dmitry, On Fri, Sep 15, 2017 at 3:30 PM, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > On Fri, Sep 15, 2017 at 2:55 PM, Jacek Anaszewski > <jacek.anaszewski@gmail.com> wrote: >> On 09/15/2017 08:34 PM, Dmitry Torokhov wrote: >>> On Thu, Sep 14, 2017 at 1:58 PM, Pavel Machek <pavel@ucw.cz> 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, >> >> 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? > > Cut what you need from this: > https://github.com/flosse/linuxconsole/blob/master/utils/fftest.c > > 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. > >> >>> 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? >> >> 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 say that while leds-gpio can be used to do whatever (you can > wire PS/2 mouse to a set of gpios and probably manage to drive it > through a set of leds-gpio devices) it does not make it right > interface for everything. We do have a standard interface for haptic > (via rumble FF), at this moment I see no reason why we need another > one. It just confuses userspace as it now needs to implement multiple > interfaces, depending on the system it runs. Android expects that HAL > will take care of hiding all of that from their upper layers and does > not really pay close attention to kernel ABIs, but I think we should. One thing I noticed is that input_ff_create_memless() also does not use high-resolution timer hence it also does not have the stop-time precision that I'm looking for. Another thing is that ff_reply duration value is maxed-out at 32767 ms (u16) while the Android/userspace requires size long for performing long notification alert. David
[toc] | [next] | [standalone]
| From | Dmitry Torokhov <dmitry.torokhov@gmail.com> |
|---|---|
| Date | 2017-09-28 07:50 +0200 |
| Subject | Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer |
| Message-ID | <uuzRT-4QC-19@gated-at.bofh.it> |
| In reply to | #1741198 |
On September 27, 2017 10:03:28 PM PDT, David Lin <dtwlin@google.com> wrote: >Dmitry, > >On Fri, Sep 15, 2017 at 3:30 PM, Dmitry Torokhov ><dmitry.torokhov@gmail.com> wrote: >> On Fri, Sep 15, 2017 at 2:55 PM, Jacek Anaszewski >> <jacek.anaszewski@gmail.com> wrote: >>> On 09/15/2017 08:34 PM, Dmitry Torokhov wrote: >>>> On Thu, Sep 14, 2017 at 1:58 PM, Pavel Machek <pavel@ucw.cz> 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, >>> >>> 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? >> >> Cut what you need from this: >> https://github.com/flosse/linuxconsole/blob/master/utils/fftest.c >> >> 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. >> >>> >>>> 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? >>> >>> 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 say that while leds-gpio can be used to do whatever (you can >> wire PS/2 mouse to a set of gpios and probably manage to drive it >> through a set of leds-gpio devices) it does not make it right >> interface for everything. We do have a standard interface for haptic >> (via rumble FF), at this moment I see no reason why we need another >> one. It just confuses userspace as it now needs to implement multiple >> interfaces, depending on the system it runs. Android expects that HAL >> will take care of hiding all of that from their upper layers and does >> not really pay close attention to kernel ABIs, but I think we should. > >One thing I noticed is that input_ff_create_memless() also does not >use high-resolution timer hence it also does not have the stop-time >precision that I'm looking for. I'll take patches for high resolution timers in ff memless, they should also help with more accurate scheduling of ramping up and fading of events. > >Another thing is that ff_reply duration value is maxed-out at 32767 ms >(u16) while the Android/userspace requires size long for performing >long notification alert. > You need unattended vibrations lasting longer than 30 seconds? Anyway, replay.length == 0 means endless IIRC, so you only need to schedule stopping. We still will clean up properly if your process crashes or exits or closes the fd. Thanks. -- Dmitry
[toc] | [prev] | [next] | [standalone]
| From | David Lin <dtwlin@google.com> |
|---|---|
| Date | 2017-09-28 21:30 +0200 |
| Message-ID | <uuMFr-4zB-5@gated-at.bofh.it> |
| In reply to | #1741207 |
On Wed, Sep 27, 2017 at 10:43 PM, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: >>One thing I noticed is that input_ff_create_memless() also does not >>use high-resolution timer hence it also does not have the stop-time >>precision that I'm looking for. > > I'll take patches for high resolution timers in ff memless, they should also help with more accurate scheduling of ramping up and fading of events. Thanks. > >> >>Another thing is that ff_reply duration value is maxed-out at 32767 ms >>(u16) while the Android/userspace requires size long for performing >>long notification alert. >> > > You need unattended vibrations lasting longer than 30 seconds? Anyway, replay.length == 0 means endless IIRC, so you only need to schedule stopping. We still will clean up properly if your process crashes or exits or closes the fd. Yes, it's up to the application to vibrate for as long as it requires. Is there any concern making the duration variable a type long? [If this is getting off-topic, I'll follow up with another email]
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web