All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Kalle Jokiniemi <kalle.jokiniemi@jolla.com>
Cc: linux-input@vger.kernel.org
Subject: Re: [PATCH 1/1] input: ff-memless: Change FF_ENVELOPE_INTERVAL to a module parameter.
Date: Thu, 3 Sep 2015 10:41:17 -0700	[thread overview]
Message-ID: <20150903174117.GA19537@dtor-ws> (raw)
In-Reply-To: <55E4148A.5050109@jolla.com>

On Mon, Aug 31, 2015 at 11:47:06AM +0300, Kalle Jokiniemi wrote:
> 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?

I'd say keep the interval between [5,50] msecs and scale it that you
have at least N points for the attack duration. I.e if you decide that
you want at least 8 points you do:

	interval = attack_duration / 8;
	interval = clamp_val(interval, 5, 50);

> 
> 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).

I do not have objections to doing this.

Thanks.

-- 
Dmitry

      reply	other threads:[~2015-09-03 17:41 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
2015-09-03 17:41     ` Dmitry Torokhov [this message]

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=20150903174117.GA19537@dtor-ws \
    --to=dmitry.torokhov@gmail.com \
    --cc=kalle.jokiniemi@jolla.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.