Some devices provide absolute axes with min/max of 0/0 (e.g. wacom's
ABS_MISC axis). Current uinput restrictions do not allow duplication of
these devices and require hacks in userspace to work around this.
If the kernel accepts physical devices with a min/max of 0/0, uinput
shouldn't disallow the same range.
Signed-off-by: Peter Hutterer <[email protected]>
---
drivers/input/misc/uinput.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index b941078..d7cc037 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -301,10 +301,14 @@ static int uinput_validate_absbits(struct input_dev *dev)
int retval = 0;
for (cnt = 0; cnt < ABS_CNT; cnt++) {
+ int min, max;
if (!test_bit(cnt, dev->absbit))
continue;
- if (input_abs_get_max(dev, cnt) <= input_abs_get_min(dev, cnt)) {
+ min = input_abs_get_min(dev, cnt);
+ max = input_abs_get_max(dev, cnt);
+
+ if ((min != 0 || max != 0) && max <= min) {
printk(KERN_DEBUG
"%s: invalid abs[%02x] min:%d max:%d\n",
UINPUT_NAME, cnt,
--
1.7.4.2
On Thu, Mar 31, 2011 at 03:05:03PM +1000, Peter Hutterer wrote:
> Some devices provide absolute axes with min/max of 0/0 (e.g. wacom's
> ABS_MISC axis). Current uinput restrictions do not allow duplication of
> these devices and require hacks in userspace to work around this.
>
> If the kernel accepts physical devices with a min/max of 0/0, uinput
> shouldn't disallow the same range.
>
Right, we should treat 0/0 as unlimited, or not specified, not
applicable.
Applied, thank you Peter.
--
Dmitry