[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7e57db42a261a54d38a3a7bb068c3ce2.squirrel@mungewell.org>
Date: Tue, 20 May 2014 19:45:44 -0400
From: simon@...gewell.org
To: "Michal MalĂ˝"
<madcatxster@...oid-pointer.net>
Cc: simon@...gewell.org, "Dmitry Torokhov" <dmitry.torokhov@...il.com>,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
jkosina@...e.cz, elias.vds@...il.com, anssi.hannula@....fi
Subject: Re: [PATCH v4 01/24] input: Add ff-memless-next module
>> Regarding the question of emulated vs. real effects, can we extend the
>> API
>> so that applications can know which effects are really supported, and
>> enable/disable emulation somehow?
>
> I suppose that a few extra flags (FF_PERIODIC_EMULATED etc.) defined in
> "uapi/linux/input.h" should suffice.
The only problem is that we probably want to maintain backward
compatibility so that older apps still see 'PERIODIC' (even though it is
emulated).
--
#define FF_RUMBLE 0x50
#define FF_PERIODIC 0x51
#define FF_CONSTANT 0x52
#define FF_SPRING 0x53
#define FF_FRICTION 0x54
#define FF_DAMPER 0x55
#define FF_INERTIA 0x56
#define FF_RAMP 0x57
--
Do we therefore have to list extra items in our capabilities?
--
static const signed short lg4ff_wheel_effects[] = {
FF_CONSTANT,
FF_PERIODIC,
FF_PERIODIC_NOT_EMULATED,
FF_AUTOCENTER,
-1
};
--
Simon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists