On Thursday, December 13, 2012, Peter Hutterer wrote:
> 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.
You are right for the need of X driver code here. However, we updated
the kernel driver soon after we realized the issue. It was "fixed" by
adding one to x/y when two fingers are on the same line vertically or
horizontally in the kernel. That happened around kernel 2.6.30 time frame.
> except for the pad which is always in proximity and didn't rely on
> multiplexing, so we could skip that.
PAD has a different story. It was not the proximity made the difference.
It was because we associated PAD events to a separate tool
(BTN_TOOL_FINGER).
To return BTN_TOOL_FINGER to single touch events, kernel merged PAD events
for Bamboo into touch events, which introduced a set of new problems in X
driver.
Ping
> 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.
> > >
------------------------------------------------------------------------------
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
