On Fri, Dec 14, 2012 at 6:39 PM, Ping Cheng <pingli...@gmail.com> wrote:
> Hi Chris,
>
> Long time no "say". What's your opinion about the patchset? Do you care to
> give an acked-by or nacked-by? Without your help, the bamboo PAD is broken
> every so often these days....
>
Sorry I haven't been able to contribute much to the project.
I'll send some comments to the patches separately.
Chris
>
> Ping
>
> On Fri, Dec 14, 2012 at 2:58 PM, Chris Bagwell <ch...@cnpbagwell.com>wrote:
>
>>
>> On Thu, Dec 13, 2012 at 9:37 PM, Peter Hutterer <peter.hutte...@who-t.net
>> > 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.
>>>
>>> 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
>>>
>>>
>> Right, except that "tool" means fingers in this case. The "old kernel
>> way" is explained in some detail on this page under the "Touchpad Overview"
>> section.
>>
>>
>> https://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Kernel_Input_Event_Overview
>>
>> The concept of that deleted code is that any user land apps need to track
>> last values sent by kernel that are shared between tools and when switching
>> tools you need to continue using the last sent values because of event
>> filtering. Since we are storing X/Y/Pressure in different "channels", when
>> switching channels the X/Y/Pressure fields need to be copied over at switch
>> time.
>>
>> For MT devices, there is not same concept of shared events so the code
>> can be deleted.
>>
>> Protocol 5 devices and any Protocol 4 with mice do in fact need similar
>> logic but we don't have it; as the Protocol 5 deleted comment alludes to.
>> We are most likely losing data during some tool/finger switch overs for
>> those devices but since they mostly work in Absolute mode almost no one
>> notices it because of fast recovery.
>>
>> FYI: I see now that I documented "Synaptics" wrong on wiki. The
>> X/Y/Pressure for syntaptics are really always bound to the FINGER tool and
>> DOUBLETAP is more an extra tool with no X/Y/Pressure associated directly
>> with it. Something closer to this:
>>
>> * BTN_TOOL_FINGER
>> * BTN_TOUCH
>> * ABS_X
>> * ABS_Y
>> * ABS_PRESSURE
>> * BTN_TOOL_DOUBLETAP
>> * BTN_LEFT
>> * BTN_RIGHT
>>
>> Chris
>>
>>
>>> >
>>> > 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
