USB: N-trig Finger Pen Multitouch fix
in [Kernel]
|
Prev: [PATCH] ARCH: x86: fix coding style issues in video-vesa.c
Next: linux-next: manual merge of the mfd tree with the tmio-mmc tree
From: Jiri Kosina on 9 Mar 2010 05:30 On Mon, 8 Mar 2010, Micki Balanga wrote: > I see quite a number of changes that handle the protocol better than my > version, would you be offended if I begin to absorb those and submit > joint patches? I'm not sure about the proper etiquette for that. > > [Micki] As mentioned in my mail we have tested the driver with > application develop by N-trig. > [Micki] Our user space application rely on these events, so if you want > to make any change I will be happy if you > [Micki] consult me. Please keep in mind that we don't want to break backwards compatibility for existing users of the current in-kernel n-trig driver. > What user space tools have you tested this driver with? It does not > seem to work well with the wacom and evdev drivers. > > [Micki] We will put on N-trig web site a DEB package Distributions based on Debian packaging system are not the only existing ones. What's usually better is to release source code package, so that distributions could eventually package it themselves for their users, if applicable. > What improvements beyond the driver that's in 2.6.33 are you targeting? > > [Micki] We will update the driver and user space application with new > features. > > > + * The driver will support MTM firwmare Pen, Finger (Up to 6) > > Is this code intended to support older firmwares as well? It would be > best not to break the driver for users with legacy firmwares without > reason. > > [Micki] There will be a DEB package for firmware upgrade. The in-kernel driver needs to support both older and newer firmware at the same time, otherwise it would bring a lot of pain to users. > > + case HID_DG_CONTACTCOUNT: > > + nt_rpt->real_fingers = value; > > + nt_rpt->fake_fingers = > > MAX_FINGERS_SUPPORT - value; > > > + if > (MAX_FINGERS_SUPPORT > > == nt_rpt->fake_fingers--) { > > Would you care to explain "fake_fingers"? I'm not really seeing why it > helps > when you already have real_fingers. It looks like you use that to > detect some > ghost events, but really again, fingers should be fine at that point. > > That does remind me that I pulled that special case when I cleaned up my > last > patch set and forgot to put it back. > > Are the fake finger events intentional or just a bug? > [Micki] As I mentioned before we developed a user space application > which analyze the data > Transferred from driver and the driver need to report about fake > fingers. I am afraid this will need much more explanation. Also, have you considered wrokign with X evdev people, so that ideally no other userspace software would eventually be needed? Thanks, -- Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |