On Wed, Nov 16, 2011 at 03:23:50PM -0600, Chris Bagwell wrote: > One update on my side. I was looking at hid-multitouch.c from > Dmitri's next branch and didn't see that ALWAYS_VALID. So I thought > it was a typo and manually mapping your "18" value to > VALID_IS_INRANGE; which we were previously setting it to. Thats why I > mentioned I thought you were setting to same quirks. > > Thanks for diff. Often a diff is worth a thousand words. > > OK, now back to your email. I'm confused about your logs. The URL > points to the tar file with multiple logs and the evtest_twofinger.log > inside it is the one I was talking about having issues.
Indeed. Those logs in the TAR file were created when I was still manually adding the device to sysfs (that is, before that very diff which includes changes to the whitelist). It looks like I neglected to set the quirks back then. Sorry. > > Now you've attached a new evtest_twofinger.log and its values look > good. So your saying this new log is from a version based on the > diff? Exactly. Cedric > If so, I'll chalk it up to some debug issue and sounds like > ALWAYS_VALID is indeed the key to this. > > Chris > > On Wed, Nov 16, 2011 at 2:48 PM, Cedric Sodhi <man...@gmx.net> wrote: > > Dear Benjamin, > > > > I applied your patch tp 3.2-jikos (uname shows 3.1, though). The > > diff to jikos' original is now [attached]. > > > > Chris says the output of evtest still signifies problems with > > multitouch: > > > >> > http://ompldr.org/iYmIzYw > >> > >> Cedric, can you send these logs to Benjamin for ideas? The HID events > >> look good but the evtest log for 2 fingers is not. The two touches > >> are fighting each other. That "-1" value is interrupted as each > >> finger is being lifted in between each new X/Y report. > >> > >> Also, can you send me and Benjamin the source code diff of what your > >> testing against kernel tree? > >> > >> The behavior in your evtest log looks like what would happen if your > >> setting the MT_QUIRK_NOT_SEEN_MEANS_UP. Since your HW only sends 1 > >> fingers worth of data per packet, you do not want that quirk. > >> > >> I'll still hold off on xf86-input-wacom issues until the events coming > >> are sane. Your current events will cause xf86-input-wacom to do all > >> kinds of weird stuff thats not worth effort to weed threw. > >> > >> Chris > > > > These logs in that tarfile were created while still manually adding the > > ID via your sysfs interface. You find yet another evtest log for > > two-finger touch attached. > > > > Cedric > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
