On Wed, Dec 12, 2012 at 11:08:17AM -0800, Ping Cheng wrote:
> On Wed, Dec 12, 2012 at 10:54 AM, Jason Gerecke <killert...@gmail.com>wrote:
>
> > It certainly doesn't hurt :) I think my biggest problem is that I never
> > really understood exactly when this code was required.
>
>
> I bet you don't want to know ;-). Chris knows this chunk of code way better
> than me. It is a long story and it is history already. I'll share it
> offline, with those who are curious...
no, please share it online so it's archived for future generations.
this code isn't that old, so if we can't even remember what it was written
for we really need to document better.
commit messages are free, we might as well use them properly.
afaict, this code was there because before the MT protocol we used the
BTN_TOOL_DOUBLETAP and friends to switch between tools. but because this was
abusing the system a bit, switching to a different tool wouldn't update the
other coordinates for that tool (the kernel would skip those events if they
were on the last-sent coordinates for the previous tool), so we had to copy
that around in the driver.
except for the pad which is always in proximity and didn't rely on
multiplexing, so we could skip that.
does this sound correct?
Cheers,
Peter
>
> Ping
>
> 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
------------------------------------------------------------------------------
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
