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...@wacom.com <javascript:;>>
> > Acked-by: Jason Gerecke <killert...@gmail.com <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?
Ping
> 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
> >
>
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
