linux-kernel - Re: [PATCH v2] Input: introduce device properties

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] [day] [month] [year] [list]

Message-ID: <20101219085428.GB5892@polaris.bitmath.org>
Date:	Sun, 19 Dec 2010 09:54:28 +0100
From:	"Henrik Rydberg" <rydberg@...omail.se>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Jiri Kosina <jkosina@...e.cz>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] Input: introduce device properties

On Sun, Dec 19, 2010 at 12:07:23AM -0800, Dmitry Torokhov wrote:
> On Sat, Dec 18, 2010 at 09:05:19PM +0100, Henrik Rydberg wrote:
> > Today, userspace sets up an input device based on the data it emits.
> > This is not always enough; a tablet and a touchscreen may emit exactly
> > the same data, for instance, but the former should be set up with a
> > pointer whereas the latter does not need to. Recently, a new type of
> > touchpad has emerged where the buttons are under the pad, which
> > changes logic without changing the emitted data. This patch introduces
> > a new ioctl, EVIOCGPROP, which enables user access to a set of device
> > properties useful during setup. The properties are given as a bitmap
> > in the same fashion as the event types, and are also made available
> > via sysfs, uevent and /proc/bus/input/devices.
> > 
> > Acked-by: Ping Cheng <pingc@...om.com>
> > Acked-by: Chase Douglas <chase.douglas@...onical.com>
> > Signed-off-by: Henrik Rydberg <rydberg@...omail.se>
> 
> Looks good to me, thanks for making changes.

Thank you, I take that as an ack, then.
 
> BTW, we need to figure out how to tell when you CC me for review/FYI but
> will push the patch through your tree and when you want me to apply the
> patch directly to my tree.

Right, the subject is supposed to tell, but more often it becomes a
question of patch ordering and testing convenience. It seems
everything queued for next has been going through my tree, so maybe
that should be the default. Had the present patch really been for
2.6.37, for example, it would have been more convenient to have it
applied directly to your tree.

Makes sense?

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/