On Tue, Feb 22, 2011 at 7:01 AM, Chris Bagwell <ch...@cnpbagwell.com> wrote:

> On Mon, Feb 21, 2011 at 9:09 PM, Ping Cheng <pingli...@gmail.com> wrote:
> > On Mon, Feb 21, 2011 at 9:19 AM, <ch...@cnpbagwell.com> wrote:
> >>
> >> From: Chris Bagwell <ch...@cnpbagwell.com>
> >>
> >> PROTOCOL_GENERIC devices send "pad" buttons along
> >> with touchscreen/touchpad events.  Since we are
> >> emulating "pad" device concept, we need to let
> >> "pad" events go through when "touch" is disabled.
> >>
> >> There seems to be a popular script floating around
> >> that toggles "touch" device on/off by using
> >> same devices "pad" buttons.  This patch allows that
> >> to work again.
> >>
> >> Signed-off-by: Chris Bagwell <ch...@cnpbagwell.com>
>

Reviewed-by: Ping Cheng <pingli...@gmail.com>

Thank you Chris. A minor reply to you inline.

PIng

> >> ---
> >>  src/wcmUSB.c |   29 +++++++++++++++--------------
> >>  1 files changed, 15 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/src/wcmUSB.c b/src/wcmUSB.c
> >> index 4aae452..cb7bf6b 100644
> >> --- a/src/wcmUSB.c
> >> +++ b/src/wcmUSB.c
> >> @@ -1312,10 +1312,6 @@ static void usbDispatchEvents(InputInfoPtr pInfo)
> >>                }
> >>        }
> >>
> >> -       /* don't send touch event when touch isn't enabled */
> >> -       if ((ds->device_type == TOUCH_ID) && !common->wcmTouch)
> >
> > I guess the root cause of the issue was device_type for PAD was not set
> at
> > this stage. If we move:
> >
> >     if (private->wcmBTNChannel != channel && btn_channel_change)
> >     {
> >         /* Force to in proximity for this special case */
> >         btn_ds->proximity = 1;
> >         btn_ds->device_type = PAD_ID;
> >         btn_ds->device_id = PAD_DEVICE_ID;
> >         btn_ds->serial_num = 0xf0;
> >     }
> >
> > or just:
> >
> >     if (private->wcmBTNChannel != channel && btn_channel_change)
> >     {
> >         btn_ds->device_type = PAD_ID;
> >         btn_ds->device_id = PAD_DEVICE_ID;
> >     }
> >
> > above the if statement, the rest can stay unchanged.
> >
>
> Not exactly.  That is because both TOUCH and PAD events can come in
> same sync window.  So we need to break them into two batches and
> execute them in two batches.  Thats why instead of returning I changed
> conditionally send touch to wcmEvent() but always send pad to
> wcmEvent().
>
> Sure, we could basically discard touch data (by forcing device to PAD
> as you show) and let it be posted in future interrupts but this goes
> ahead and handles them now.
>

Since it is specific to generic protocol, let's send both touch and pad data
in the same routine.
------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
_______________________________________________
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Reply via email to