linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kalle Jokiniemi <kalle.jokiniemi@jolla.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org
Subject: Re: [PATCH 1/1] input: ff-memless: Change FF_ENVELOPE_INTERVAL to a module parameter.
Date: Mon, 31 Aug 2015 11:47:06 +0300	[thread overview]
Message-ID: <55E4148A.5050109@jolla.com> (raw)
In-Reply-To: <20150829002925.GA8298@dtor-ws>

Hi,

On 29.08.2015 03:29, Dmitry Torokhov wrote:
> Hi Kalle,
>
> On Fri, Aug 28, 2015 at 02:56:33PM +0300, Kalle Jokiniemi wrote:
>> Sometimes you need to have tighter control over the ff-memless
>> effects. E.g. when creating short button / VKB press effects,
>> the effect duration is typically <= 40ms, and you want to have
>> a short acceleration period in beginning and fade out the end
>> to avoid "electric tooth brush" effect. With 50ms envelope
>> interval this control is not possible.
>>
>> To allow this control without patching over ff-memless, change the
>> FF_ENVELOPE_INTERVAL macro to a module parameter that can be modified
>> via kernel command line or during runtime from
>> /sys/module/ff_memless/parameters/ff_envelope_interval sysfs file.
>
> How would users know that they need to change this parameter? Could we
> maybe adjust sampling time dynamically, based on the attack length of
> the envelope?

Well, I'm looking after some parts of the Sailfish OS haptics / vibrator 
parts, and consider myself a user. For haptic effects (e.g. the VKB 
example above), I know I need as short as I can get to be able to tune 
those effects to work best with the Hardware I'm working with. Then for 
long alarm vibrations, the interval doesn't matter that much. But 
typically I would just set it to the smallest I can get with HZ setting 
the kernel has.

I've been thinking the "user" for this setting more as a system 
administrator / OS maintainer / device maker setting. But your idea 
could maybe work. Top of my head the downside would be added complexity, 
and slight "unpredictability" of the function if the timing changes 
dynamically. Would we then again need a user space setting for the 
threshold where to start using longer timers?

BTW, how would you feel about hr timers instead of jiffy based timing in 
ff-memless? That is a bit of a bottle neck for me (I see some jitter on 
the first event and typical 100Hz kernel only gives 10ms control interval).

- Kalle

>
> Thanks.
>

  reply	other threads:[~2015-08-31  8:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-28 11:56 [PATCH 1/1] input: ff-memless: Change FF_ENVELOPE_INTERVAL to a module parameter Kalle Jokiniemi
2015-08-29  0:29 ` Dmitry Torokhov
2015-08-31  8:47   ` Kalle Jokiniemi [this message]
2015-09-03 17:41     ` Dmitry Torokhov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55E4148A.5050109@jolla.com \
    --to=kalle.jokiniemi@jolla.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).