linux-kernel - Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

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]

Date:	Thu, 20 May 2010 00:11:58 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Peter Hutterer <peter.hutterer@...-t.net>
Cc:	Henrik Rydberg <rydberg@...omail.se>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	Mika Kuoppala <mika.kuoppala@...ia.com>,
	Benjamin Tissoires <tissoire@...a.fr>,
	Stephane Chatty <chatty@...c.fr>,
	Rafi Rubin <rafi@...s.upenn.edu>,
	Michael Poole <mdpoole@...ilus.org>
Subject: Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

On Thu, May 20, 2010 at 10:13:24AM +1000, Peter Hutterer wrote:
> On Wed, May 19, 2010 at 02:12:14PM +0200, Henrik Rydberg wrote:
> > Peter Hutterer wrote:
> > > On Tue, May 18, 2010 at 10:10:29PM +0200, Henrik Rydberg wrote:
> > >> This patch adds documentation for the SYN_MT_SLOT event and gives
> > >> examples of how to use the event slot protocol.
> > > 
> > > thanks, this is really nice documentation! the approach seems good, though I
> > > do have a few questions inline.
> > > 
> > [...]
> > > 
> > > Is there a limit on the number of slots?
> > 
> > The slots are dynamically allocated by the driver, so there is no practical
> > limit. Each slot currently takes 44 bytes, and allocating a few kilobytes of
> > kernel memory is not a problem.
> > 
> > > Will all drivers with ABS_MT_TRACKING_ID use slots? if not, how can I know
> > > in advance if a device may use slots or not?
> > 
> > Eventually, this might become true, but you are pointing at one of the weaker
> > points of the current setup. There is no bit field for the EV_SYN events, so
> > there is no way to know in advance if SYN_MT_SYNC or SYN_MT_SLOT is used. This
> > could quite possibly be added to the EVIO interface. Meanwhile, the method I use
> > is to detect the first SYN_MT_SLOT and select parser based on that information.
> 
> I'd really prefer if there was some way to detect this. While I'm not quite
> sure how the matching X drivers would look like it's likely that the setups
> will be different for drivers that support slots and those that don't.
> e.g. those that don't have slots simply send events as valuators, those that
> do may split into multiple devices.
> 
> Doing this at runtime - after the device has been set up is...tricky.
> 

Right, I think we should try our hardest to allow userspace base
protocol decoding decisions on device capabilities and not the event
datastream. What about moving from SYN_MT_SLOT to ABS_MT_SLOT? I think
it makes more sense since it is not a simple marker but carries data
(slot number).

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