[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1274539582.13705.132.camel@cndougla-ubuntu>
Date: Sat, 22 May 2010 10:46:22 -0400
From: Chase Douglas <chase.douglas@...onical.com>
To: Henrik Rydberg <rydberg@...omail.se>
Cc: Rafi Rubin <rafi@...s.upenn.edu>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Ping Cheng <pinglinux@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
Mika Kuoppala <mika.kuoppala@...ia.com>,
Peter Hutterer <peter.hutterer@...-t.net>,
Benjamin Tissoires <tissoire@...a.fr>,
Stephane Chatty <chatty@...c.fr>,
Michael Poole <mdpoole@...ilus.org>
Subject: Re: [PATCH 2/2] input: mt: Document the MT event slot protocol
(rev3)
On Sat, 2010-05-22 at 12:38 +0200, Henrik Rydberg wrote:
> Getting serious, it is anyone's guess what will happen next, but I was picturing
> a table, with a large multitouch screen and buttons along the side of the table.
> Sure, we can do "ABS_BTN_0", "ABS_BTN_1", etc, but with slots in place, it seems
> more natural to use something like "ABS_MT_BTN_X". While at it, REL_MT event
> makes sense for those touchscreen techniques which register changes, like
> acoustic pulse recognition.
Shouldn't this be handled in userspace? I don't think we want to be
quirking drivers for instances where the same touchscreen is overlaid on
buttons in some cases, but not in others. If we don't quirk, we'd need
some mechanism to tell the driver about such buttons.
-- Chase
--
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