Re: [Linuxwacom-devel] [PATCH 3/4 v2] Send generic PAD events before other events
On Mon, Dec 17, 2012 at 9:20 AM, Chris Bagwell wrote:
>
>
>
> On Sun, Dec 16, 2012 at 11:35 PM, Ping Cheng wrote:
>
>> On Sunday, December 16, 2012, Ping Cheng wrote:
>>
>>> On Sunday, December 16, 2012, Chris Bagwell wrote:
>>>
On Sun, Dec 16, 2012 at 7:17 PM, Ping Cheng wrote:
> On Sun, Dec 16, 2012 at 1:40 PM, Chris Bagwell
> wrote:
>
>>
>>
>>
>> On Thu, Dec 13, 2012 at 2:18 PM, Ping Cheng 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
>>> Acked-by: Jason Gerecke
>>> ---
>>> 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 can not sleep well without getting the job done ;-).
>>
>> No, we can not drop this patch. Although type and prox are good for PAD,
>> ds will never be on PAD channel for generic devices. We do not know if
>> there are touch events from a packet or not until after we parsed the
>> packet. So, calling wcmEvent immediately is the best option if we do not
>> want to go through all the other channels here.
>>
>
> I see what your saying now by ds will not be PAD channel but I still don't
> think think duplicating the event dispatch logic is correct way forward.
> We should either 1) fix usbChooseChannel() so that it is choosing the
> correct channel as PAD channel by peaking into the events or the simpler 2)
> make ds point to PAD channel any time we detect button events. Here is
> modification of your patch:
>
> +
> + /* Generic protocol will not send a BTN_TOOL_* or
> serial # when only
> +* a PAD button is sent and usbChooseChannel()
> will choose wrong.
> +* Force ds to button channel when detected to
> handle this case.
>
> +*/
> + if ((common->wcmProtocolLevel ==
> WCM_PROTOCOL_GENERIC)
> + && (common->wcmChannel[private->
> wcmBTNChannel].dirty))
> +{
> +ds =
> &common->wcmChannel[private->wcmBTNChannel].work;
> +dslast =
> &common->wcmChannel[private->wcmBTNChannel].valid.state;
> + }
>
> Since ds is now pointing at PAD instead of uninitialized channel 0, the
> if() block will stop incorrectly executing, and the wcmEvent() logic will
> only have a single code path to maintain.
>
> Although we wil
Re: [Linuxwacom-devel] [PATCH 3/4 v2] Send generic PAD events before other events
On Sun, Dec 16, 2012 at 11:35 PM, Ping Cheng wrote:
> On Sunday, December 16, 2012, Ping Cheng wrote:
>
>> On Sunday, December 16, 2012, Chris Bagwell wrote:
>>
>>>
>>> On Sun, Dec 16, 2012 at 7:17 PM, Ping Cheng wrote:
>>>
On Sun, Dec 16, 2012 at 1:40 PM, Chris Bagwell wrote:
>
>
>
> On Thu, Dec 13, 2012 at 2:18 PM, Ping Cheng 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
>> Acked-by: Jason Gerecke
>> ---
>> 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 can not sleep well without getting the job done ;-).
>
> No, we can not drop this patch. Although type and prox are good for PAD,
> ds will never be on PAD channel for generic devices. We do not know if
> there are touch events from a packet or not until after we parsed the
> packet. So, calling wcmEvent immediately is the best option if we do not
> want to go through all the other channels here.
>
I see what your saying now by ds will not be PAD channel but I still don't
think think duplicating the event dispatch logic is correct way forward.
We should either 1) fix usbChooseChannel() so that it is choosing the
correct channel as PAD channel by peaking into the events or the simpler 2)
make ds point to PAD channel any time we detect button events. Here is
modification of your patch:
+
+ /* Generic protocol will not send a BTN_TOOL_* or
serial # when only
+* a PAD button is sent and usbChooseChannel() will
choose wrong.
+* Force ds to button channel when detected to
handle this case.
+*/
+ if ((common->wcmProtocolLevel ==
WCM_PROTOCOL_GENERIC)
+ && (common->wcmChannel[private->
wcmBTNChannel].dirty))
+{
+ds =
&common->wcmChannel[private->wcmBTNChannel].work;
+dslast =
&common->wcmChannel[private->wcmBTNChannel].valid.state;
+ }
Since ds is now pointing at PAD instead of uninitialized channel 0, the
if() block will stop incorrectly executing, and the wcmEvent() logic will
only have a single code path to maintain.
Although we will also be resetting ds pointer for Movement+PAD events as
well; it should be no problem since we just need it pointing at any one of
the two valid and initialized ds fields.
> Chris, can I assume your Acked/Reviewed-by for
Re: [Linuxwacom-devel] [PATCH 3/4 v2] Send generic PAD events before other events
On Sunday, December 16, 2012, Ping Cheng wrote:
> On Sunday, December 16, 2012, Chris Bagwell wrote:
>
>>
>> On Sun, Dec 16, 2012 at 7:17 PM, Ping Cheng wrote:
>>
>>> On Sun, Dec 16, 2012 at 1:40 PM, Chris Bagwell wrote:
>>>
On Thu, Dec 13, 2012 at 2:18 PM, Ping Cheng 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
> Acked-by: Jason Gerecke
> ---
> 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 can not sleep well without getting the job done ;-).
No, we can not drop this patch. Although type and prox are good for PAD, ds
will never be on PAD channel for generic devices. We do not know if there
are touch events from a packet or not until after we parsed the packet. So,
calling wcmEvent immediately is the best option if we do not want to go
through all the other channels here.
Chris, can I assume your Acked/Reviewed-by for the patch set?
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
Re: [Linuxwacom-devel] [PATCH 3/4 v2] Send generic PAD events before other events
On Sunday, December 16, 2012, Chris Bagwell wrote:
>
> On Sun, Dec 16, 2012 at 7:17 PM, Ping Cheng
>
> > wrote:
>
>> On Sun, Dec 16, 2012 at 1:40 PM, Chris Bagwell
>>
>> > wrote:
>>
>>>
>>>
>>>
>>> On Thu, Dec 13, 2012 at 2:18 PM, Ping Cheng
>>>
>>> > 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 >>> 'cvml', 'pingli...@gmail.com');>>
Acked-by: Jason Gerecke >>> '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
Re: [Linuxwacom-devel] [PATCH 3/4 v2] Send generic PAD events before other events
On Sun, Dec 16, 2012 at 7:17 PM, Ping Cheng wrote:
> On Sun, Dec 16, 2012 at 1:40 PM, Chris Bagwell wrote:
>
>>
>>
>>
>> On Thu, Dec 13, 2012 at 2:18 PM, Ping Cheng 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
>>> Acked-by: Jason Gerecke
>>> ---
>>> 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
Re: [Linuxwacom-devel] [PATCH 3/4 v2] Send generic PAD events before other events
On Sun, Dec 16, 2012 at 1:40 PM, Chris Bagwell wrote:
>
>
>
> On Thu, Dec 13, 2012 at 2:18 PM, Ping Cheng 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
>> Acked-by: Jason Gerecke
>> ---
>> 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 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
Re: [Linuxwacom-devel] [PATCH 3/4 v2] Send generic PAD events before other events
On Thu, Dec 13, 2012 at 2:18 PM, Ping Cheng 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
> Acked-by: Jason Gerecke
> ---
> 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?
I can tell from the if() that its a Generic device... which one though?
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. 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.
Chris
}
> } /* next event */
>
> --
> 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
>
--
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
[Linuxwacom-devel] [PATCH 3/4 v2] Send generic PAD events before other events
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
Acked-by: Jason Gerecke
---
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);
+ }
}
} /* next event */
--
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
