Messages in this thread | | | Date | Tue, 10 Apr 2012 08:25:06 +1000 | From | NeilBrown <> | Subject | Re: [PATCH RESEND] LEDS-One-Shot-Timer-Trigger-implementation |
| |
On Sun, 8 Apr 2012 17:06:46 -0700 Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> On Mon, Apr 09, 2012 at 09:42:19AM +1000, NeilBrown wrote:
> > Also, I don't think 'ff' allows for "vibrate for N milliseconds". > > It appears that one uses the "rumble" effect and have to say "turn it on", > > then "turn it off". Is that correct? > > No, it is not. > > > I found 'struct ff_replay' which has a 'length' which is a duration, but it > > doesn't seem to be used. > > It does, see drivers/input/ff-memless.c where it us used to schedule > when effect starts and how long it should play. Non memoryless devices > (such as iforce) are supposed to schedule effects themselves. > > > > > How would you tell the force feedback framework to play the vibrator for > > 120ms, then stop? > > By specifying replay->length = 120
You seem to make a convincing case. I'll explore this some more and see what it is like in practice.
Clipping from above:
> > Well, if you consider "input" is really "hid" then FF is really > appropriate for iterfacing with a human. >
A slightly related question. My phone has accelerometers in it. I want to use them entirely a human-interface-devices. The device itself can detect inversions and taps and jerks and I want to report just those to user-space, preferably via the input (aka hid :-) subsystem. However my understanding is that accelerometer drivers aren't welcome as input drivers. Is that still true? There is nothing 'industrial' about these accelerometers so I would like to avoid 'iio'. What are your thoughts about this?
Thanks, NeilBrown [unhandled content-type:application/pgp-signature] | |