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.
>
next prev parent 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).