On Sun, Dec 16, 2012 at 7:17 PM, Ping Cheng <pingli...@gmail.com> wrote:
> On Sun, Dec 16, 2012 at 1:40 PM, Chris Bagwell <ch...@cnpbagwell.com>wrote:
>
>>
>>
>>
>> On Thu, Dec 13, 2012 at 2:18 PM, Ping Cheng <pingli...@gmail.com> wrote:
>>
>>> If we wait until we finish other verifications, we could miss
>>> PAD events since they will be filtered out when there are no
>>> motion events sent simultaneously.
>>>
>>
>>
>>> Signed-off-by: Ping Cheng <pingli...@gmail.com>
>>> Acked-by: Jason Gerecke <killert...@gmail.com>
>>> ---
>>> src/wcmUSB.c | 13 +++++++++++++
>>> 1 file changed, 13 insertions(+)
>>>
>>> diff --git a/src/wcmUSB.c b/src/wcmUSB.c
>>> index 0ea2093..f15a6a2 100644
>>> --- a/src/wcmUSB.c
>>> +++ b/src/wcmUSB.c
>>> @@ -1655,6 +1655,19 @@ static void usbDispatchEvents(InputInfoPtr pInfo)
>>> {
>>> usbParseKeyEvent(common, event, channel);
>>> usbParseBTNEvent(common, event,
>>> private->wcmBTNChannel);
>>> +
>>> + /* send PAD events now for generic devices.
>>> Otherwise,
>>> + * they are filtered out when there are no
>>> motion events.
>>> + */
>>> + if ((common->wcmProtocolLevel ==
>>> WCM_PROTOCOL_GENERIC)
>>> + &&
>>> (common->wcmChannel[private->wcmBTNChannel].dirty))
>>> + {
>>> + DBG(10, common, "Dirty flag set on
>>> channel %d; "
>>> + "sending event.\n",
>>> private->wcmBTNChannel);
>>> +
>>> common->wcmChannel[private->wcmBTNChannel].dirty = FALSE;
>>> + wcmEvent(common, private->wcmBTNChannel,
>>> +
>>> &common->wcmChannel[private->wcmBTNChannel].work);
>>> + }
>>>
>>
>>
>> I don't understand this one. How are they "filtered" out? Is
>> usbDispatchEvents() returning early or is it some other function?
>>
>
> It is returned immediarely by the next if statement since both device_type
> and proximity are zero when no touch events.
>
I see. Now I can understand why you had patch 1/4 as well.
The intent was that the button channel's ds->device_type and ds->proximity
is fixed and initialized one time up front by usbWcmInitPadState(). That
function was added specifically because its known that no BTN_TOOL_* like
event will kick the code to set up PAD's device_type and proximity for
generic devices.
The code in 1/4 patch was being to agressive and setting these fields to
zero and then confusing all kinds of stuff from there. If we submit patch
1/4 then can this patch be dropped? Does it do anything useful once
device_type and proximity stay at good values for PAD?
Chris
> I can tell from the if() that its a Generic device... which one though?
>>
>
> All generic devices that support PAD the new way in the kernel.
>
>
>
>> I suspect the events get ignored because we are not initlizing the ds
>> structure correctly. I'd prefer to get that resolved instead of
>> duplicating logic in two places.
>>
>
> For generic PAD, we can not initialize ds correctly. There is no ds for
> generic PAD. It is ride on one of the touch points, normally the first one.
>
>
>> Or if we decide this route is best/easiest then I'd prefer if we at least
>> move all Button processing earlier and then at the for() loop below we skip
>> over button channel always.
>>
>
> Other PADs do not need this route since they have their own channel (ds).
>
> Ping
>
------------------------------------------------------------------------------
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
