If a magnitude in the output report is lower than 2, i.e. 1 or 0,
the corresponding rumble motor shakes irregularly,
instead of being turned (almost) off like when magnitude 2 is used.
On the other hand, if a magnitude is higher than 0xfd, i.e 0xfe or 0xff,
the corresponding rumble motor shakes irregularly with a rotation speed
lower than when magnitude 0xfd is used.
>From 0x02 to 0xfd, the device behaves well:
a monotonic increase of rotation speed.
This applies to both weak and strong rumble motor types.
This patch fixes this issue by clamping magnitudes from 0x02 to 0xfd.
This behaviour is observed on the Formula Vibration wheel (ca04).
However it's not present on the Wingman Rumblepad (c20a) device,
yet the clamping has no effect on the haptic side,
so that special case handling is not needed.
Discussion on http://www.spinics.net/lists/linux-input/msg30711.html
Note: The same thing appears to happen in the Windows Logitech driver,
except the max clamping bound is not 0xfd, but 0xfe.
Experimentally, I proved this to be wrong.
Tested-by: Hendrik Iben <[email protected]>
Signed-off-by: Elias Vanderstuyft <[email protected]>
Cc: Edgar Simo-Serra <[email protected]>
Cc: Michal Malý <[email protected]>
Cc: [email protected]
Cc: [email protected]
---
drivers/hid/hid-lg2ff.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/hid/hid-lg2ff.c b/drivers/hid/hid-lg2ff.c
index 0e3fb1a..e180e1e 100644
--- a/drivers/hid/hid-lg2ff.c
+++ b/drivers/hid/hid-lg2ff.c
@@ -38,12 +38,17 @@ static int play_effect(struct input_dev *dev, void *data,
struct lg2ff_device *lg2ff = data;
int weak, strong;
+#define CLAMP_QUIRK(x) do { if (x < 2) x = 2; else if (x > 0xfd) x = 0xfd; } \
+ while (0)
+
strong = effect->u.rumble.strong_magnitude;
weak = effect->u.rumble.weak_magnitude;
if (weak || strong) {
weak = weak * 0xff / 0xffff;
strong = strong * 0xff / 0xffff;
+ CLAMP_QUIRK(weak);
+ CLAMP_QUIRK(strong);
lg2ff->report->field[0]->value[0] = 0x51;
lg2ff->report->field[0]->value[2] = weak;
--
1.8.3.1
Since this patch haven't been applied yet, I withdraw this patch for
the following reason:
It will get in as a part of the move to ff-memless-next.
Elias
On Wed, 9 Apr 2014, Elias Vanderstuyft wrote:
> Since this patch haven't been applied yet, I withdraw this patch for
> the following reason:
> It will get in as a part of the move to ff-memless-next.
Okay, I am ignoring it for now. Thanks,
--
Jiri Kosina
SUSE Labs