From: Peter H. <pet...@wh...> - 2012-12-17 05:31:37
|
On Thu, Dec 13, 2012 at 10:19:09PM -0800, Ping Cheng wrote: > On Thursday, December 13, 2012, Peter Hutterer wrote: > > > On Thu, Dec 13, 2012 at 12:16:52PM -0800, Ping Cheng wrote: > > > We use true MT protocol for MT devices in kernel now. This code > > > was introduced to deal with ABS_TOOL_*TAP events loss issue. It > > > is uncessary any more. And its existence makes it hard to support > > > generic PAD cleanly. > > > > > > Signed-off-by: Ping Cheng <pi...@wa... <javascript:;>> > > > Acked-by: Jason Gerecke <kil...@gm... <javascript:;>> > > > --- > > > v2: only patch 2/4 has code change from Jason's comments. To ease the > > review > > > and merge effort, I updated all to v2 with acked-by and reviewed-by tags. > > > > I honestly don't know this code well enough to do more than a cursory > > review (on all 4 patches), but is there any chance we can have test-cases > > for this? or does it rely on kernel versions too much? > > > Yes, it relies on the kernel version and the device (Bamboo2, the 2FG touch > series). > > How much chance do we have for a user to run kernel 2.6.30 with our latest > X driver which does not support X servers older than 1.7? I personally don't care about 2.6.30, but I do about 2.6.32 (for obvious reasons :). Note that the kernel is somewhat of a special case too, you can run latest userspace on an old kernel, so in theory. we can't run an older X server with the new driver, but i'm sure we can run on most 2.6 kernels. Cheers, Peter > > > --- > > > src/wcmUSB.c | 34 ++-------------------------------- > > > 1 file changed, 2 insertions(+), 32 deletions(-) > > > > > > diff --git a/src/wcmUSB.c b/src/wcmUSB.c > > > index e192489..4b5f53b 100644 > > > --- a/src/wcmUSB.c > > > +++ b/src/wcmUSB.c > > > @@ -37,7 +37,6 @@ typedef struct { > > > Bool wcmPenTouch; > > > Bool wcmUseMT; > > > int wcmMTChannel; > > > - int wcmPrevChannel; > > > int wcmEventCnt; > > > struct input_event wcmEvents[MAX_USB_EVENTS]; > > > int nbuttons; /* total number of buttons */ > > > @@ -1601,11 +1600,8 @@ static void usbDispatchEvents(InputInfoPtr pInfo) > > > return; > > > } > > > > > > - /* Protocol 5 devices have some complications related to DUALINPUT > > > - * support and can not use below logic to recover from input > > > - * event filtering. Instead, just live with occasional dropped > > > - * event. Since tools are dynamically assigned a channel #, the > > > - * structure must be initialized to known starting values > > > + /* Protocol 5 tools are dynamically assigned with channel numbers. > > > + * The structure must be initialized to known starting values > > > * when first entering proximity to discard invalid data. > > > */ > > > if (common->wcmProtocolLevel == WCM_PROTOCOL_5) > > > @@ -1614,32 +1610,6 @@ static void usbDispatchEvents(InputInfoPtr pInfo) > > > memset(&common->wcmChannel[channel],0, > > > sizeof(WacomChannel)); > > > } > > > - else > > > - { > > > - /* Because of linux input filtering, each switch to a new > > > - * tool is required to have its initial values match values > > > - * of previous tool. > > > - * > > > - * For normal case, all tools are in channel 0 and so > > > - * no issue. Protocol 4 2FGT devices split between > > > - * two channels though and so need to copy data between > > > - * channels to prevent loss of events; which could > > > - * lead to cursor jumps. > > > - * > > > - * PAD device is special. It shares no events > > > - * with other channels and is always in proximity. > > > - * So it requires no copying of data from other > > > - * channels. > > > - */ > > > - if (private->wcmPrevChannel != channel && > > > - channel != PAD_CHANNEL && > > > - private->wcmPrevChannel != PAD_CHANNEL) > > > - { > > > - common->wcmChannel[channel].work = > > > - > > common->wcmChannel[private->wcmPrevChannel].work; > > > - private->wcmPrevChannel = channel; > > > - } > > > - } > > > > > > ds = &common->wcmChannel[channel].work; > > > dslast = common->wcmChannel[channel].valid.state; > > > -- > > > 1.7.10.4 > > > > > |