It certainly doesn't hurt :) I think my biggest problem is that I never
really understood exactly when this code was required. It makes sense that
only MT using *TAP events would need it (or dual-track, but that's protocol
5), so I don't really see any problem given the testing you've done.
Jason
---
When you're rife with devastation / There's a simple explanation:
You're a toymaker's creation / Trapped inside a crystal ball.
And whichever way he tilts it / Know that we must be resilient
We won't let them break our spirits / As we sing our silly song.
On Wed, Dec 12, 2012 at 10:39 AM, Ping Cheng <pingli...@gmail.com> wrote:
> On Wed, Dec 12, 2012 at 9:45 AM, Jason Gerecke <killert...@gmail.com>wrote:
>
>> Though I can't quite convince myself that this is safe, I don't see any
>> problems with it.
>>
>> Acked-By: Jason Gerecke <killert...@gmail.com>
>>
>
> Will I say it is tested on older and new systems make it easier to
> convince you?
>
> Ping
>
>
>> Jason
>>
>> ---
>> When you're rife with devastation / There's a simple explanation:
>> You're a toymaker's creation / Trapped inside a crystal ball.
>> And whichever way he tilts it / Know that we must be resilient
>> We won't let them break our spirits / As we sing our silly song.
>>
>>
>>
>> On Thu, Dec 6, 2012 at 4:20 PM, Ping Cheng <pingli...@gmail.com> 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>
>>> ---
>>> 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
>>>
>>
>>
>
------------------------------------------------------------------------------
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
