lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110128173936.GD6252@core.coreip.homeip.net>
Date:	Fri, 28 Jan 2011 09:39:37 -0800
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Henrik Rydberg <rydberg@...omail.se>
Cc:	Benjamin Tissoires <benjamin.tissoires@...c.fr>,
	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 01:09:45PM +0100, Henrik Rydberg wrote:
> 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?
> 

Yes, a separate ioctl with explicit slot number is much better option.
Then it is automatically multi-thread safe and just does not look
ugly as hell.

Thanks.

-- 
Dmitry
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ