linux-kernel - Re: [RFC v2 03/10] hid-multitouch: support for PixCir-based panels

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: <20110107172707.GA6095@polaris.bitmath.org>
Date:	Fri, 7 Jan 2011 18:27:07 +0100
From:	"Henrik Rydberg" <rydberg@...omail.se>
To:	Benjamin Tissoires <benjamin.tissoires@...c.fr>
Cc:	Stephane Chatty <chatty@...c.fr>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Jiri Kosina <jkosina@...e.cz>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC v2 03/10] hid-multitouch: support for PixCir-based panels

> > But the mt_input_mapped function did not change - needs to change too.
> 
> I can not see any differences between mt_input_mapped and those found
> in 3m and egalax. Can you point me exactly what I should add please?

My bad - it seems your tree does contain the right function. Another
reason to have the patches in mail. :-)

> >> - The Egalax problem: I am pretty sure that Stéphane took this driver
> >> into account when writing the original patch. BTW I propose to
> >> postpone the problem for 2.6.39.
> >
> > This driver is aiming at engulfing a larger set of drivers, and as
> > such, should be prepared sensibly, IMO. Rushing things will only cause
> > us grief further down the road.
> >
> 
> So, have you got any clue (or even better, can you test a solution)
> for those devices?

Yes I can, but I will not be available the coming couple of days, so
the timing is a bit off. I agree with you that we do not need to solve
every issue right now, but I know for a fact that the newer DWAV
firmware has no touch frame indication, and does not assume the
not-seen-means-up behavior. Perhaps it is enough to just add the
quirks field to the class, define one or two quirks currently in use,
and leave the rest for later. Sounds reasonable?

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