[PATCH 3/3] input: Add FF_TRIGGER_RUMBLE capability bit

[Guillaume Casal <guillaume.casal.42@gmail.com>]

The preceding patches let userspace ask for rumble in the motors located
under the triggers, but give it no way to find out whether the device has
such motors at all. Without that, an application can only set the new
magnitudes and hope, and it cannot tell a device that ignores them from
one that has no trigger motors.

Add FF_TRIGGER_RUMBLE as a capability bit. Drivers that fill in the
trigger magnitudes advertise it with

	input_set_capability(dev, EV_FF, FF_TRIGGER_RUMBLE);

and userspace tests for it in the EVIOCGBIT(EV_FF) bitmap, exactly as it
already tests for FF_RUMBLE.

It is deliberately not an effect type. The magnitudes keep travelling
inside struct ff_rumble_effect and FF_RUMBLE remains the transport, so
FF_EFFECT_MIN and FF_EFFECT_MAX are untouched. Placing it at 0x62, above
FF_AUTOCENTER, keeps it out of the effect id space whose upper bound
FF_MAX_EFFECTS already documents. Unlike its neighbours FF_GAIN and
FF_AUTOCENTER it is read-only: it reports what the hardware has rather
than something userspace sets, and it is never used as an effect id.

Signed-off-by: Guillaume Casal <guillaume.casal.42@gmail.com>
---
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -528,6 +528,7 @@
 
 #define FF_GAIN		0x60
 #define FF_AUTOCENTER	0x61
+#define FF_TRIGGER_RUMBLE	0x62
 
 /*
  * ff->playback(effect_id = FF_GAIN) is the first effect_id to