On Thu, Dec 13, 2012 at 10:08:07PM -0800, Ping Cheng wrote:
> 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.
in my interest of course: the RHEL6 kernel is based on 2.6.32 and MT came
after that, how is this kernel affected?
Cheers,
Peter
>
>
> > 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
