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....
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
