[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110127120945.GC15626@polaris.bitmath.org>
Date: Thu, 27 Jan 2011 13:09:45 +0100
From: "Henrik Rydberg" <rydberg@...omail.se>
To: Benjamin Tissoires <benjamin.tissoires@...c.fr>
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>,
Ping Cheng <pingc@...om.com>, Jiri Kosina <jkosina@...e.cz>,
Chris Bagwell <chris@...bagwell.com>,
Rafi Rubin <rafi@...s.upenn.edu>,
Stephane Chatty <chatty@...-enac.fr>,
Peter Hutterer <peter.hutterer@...-t.net>,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC 2/2] input: evdev: Add EVIOC mechanism to extract the MT
slot state
On Thu, Jan 27, 2011 at 11:35:47AM +0100, Benjamin Tissoires wrote:
> This patch adds the ability to extract the MT slot state sequentially
> via EVIOCGABS. The slot parameter is first selected by calling
> EVIOCSABS with ABS_MT_SLOT as argument, followed by a set of EVIOCGABS
> calls. The slot selection is local to the evdev client handler, and
> does not affect the actual input state.
Ok - it seemed like a reasonable idea at the time, but..
> @@ -767,9 +769,10 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
> if (size < sizeof(struct input_absinfo))
> abs.resolution = 0;
>
> - /* We can't change number of reserved MT slots */
> - if (t == ABS_MT_SLOT)
> - return -EINVAL;
> + if (t == ABS_MT_SLOT) {
> + client->slot = abs.value;
> + return 0;
> + }
...this just does not look right. Perhaps there should really be a
different ioctl to retrieve the slot values instead. Dmitry?
Thanks,
Henrik
--
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