On Sunday, December 16, 2012, Chris Bagwell wrote:
>
> On Sun, Dec 16, 2012 at 7:17 PM, Ping Cheng
> <pingli...@gmail.com<javascript:_e({}, 'cvml', 'pingli...@gmail.com');>
> > wrote:
>
>> On Sun, Dec 16, 2012 at 1:40 PM, Chris Bagwell
>> <ch...@cnpbagwell.com<javascript:_e({}, 'cvml', 'ch...@cnpbagwell.com');>
>> > wrote:
>>
>>>
>>>
>>>
>>> On Thu, Dec 13, 2012 at 2:18 PM, Ping Cheng
>>> <pingli...@gmail.com<javascript:_e({}, 'cvml', '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 <javascript:_e({},
>>>> 'cvml', 'pingli...@gmail.com');>>
>>>> Acked-by: Jason Gerecke <killert...@gmail.com <javascript:_e({},
>>>> 'cvml', '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?
>
I have to test it again to be sure. I think this patch was needed too. Will
do it tomorrow.
Thanks.
Ping
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
