linux-kernel - Re: input: mt: Software finger tracking in the kernel?

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: <4BA54541.5030900@euromail.se>
Date:	Sat, 20 Mar 2010 22:59:29 +0100
From:	Henrik Rydberg <rydberg@...omail.se>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
CC:	Henrik Rydberg <rydberg@...esh.se>,
	linux-input <linux-input@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: input: mt: Software finger tracking in the kernel?

Dmitry Torokhov wrote:
> Hi Henrik
[...]
> I am not sure if input core itself is the proper place to do such
> thing, I'd envisioned something more like a library providing common
> code that drivers could opt in to use, like we hane ff-memless for
> memory-less force-feedback devices.
> 
> Does it make any sense? I guess post the skeleton of the code and we can
> discuss further.

Yes, input core as in input*.c might be wrong. The big thing is that the events
most likely have to be deferred to the bottom half. Otherwise, the scheme would
have fit rather nicely on top of the current filtering in input_device. The
ideas I am currently looking at are:

1. Expand on the new event filtering mechanism, providing a sort of rewrite
functionality which can schedule events for later injection into the event stream.

2. Add additional logic to evdev so that it buffers MT events and flushes the
reworked events directly onto the clients.

3. Add a new multitouch handler, mtdev, which by default does event deferral,
only emitting events by scheduling them upon SYN_REPORT requests.

To my untrained eye, all three options could be made to work with acceptable
latency. Number three probably means applications (read X) have to keep open
both evdev and mtdev, which might be confusing. Number one is quite general, but
probably contains hidden (to me) difficulties. Number two sounds pretty
straight-forward, although tapping into the code somewhat through the back door.

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/