Re: [Linuxwacom-devel] [PATCH 1/4] Remove channel duplication code for generic devices
On Thu, Dec 13, 2012 at 9:37 PM, Peter Hutterer peter.hutte...@who-t.netwrote:
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;
Re: [Linuxwacom-devel] [PATCH 1/4] Remove channel duplication code for generic devices
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.netwrote:
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;
Re: [Linuxwacom-devel] [PATCH 1/4] Remove channel duplication code for generic devices
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.comwrote:
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
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.comwrote:
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
[Linuxwacom-devel] [PATCH 1/4] Remove channel duplication code for generic devices
On Thursday, December 13, 2012, Peter Hutterer 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.
You are right for the need of X driver code here. However, we updated
the kernel driver soon after we realized the issue. It was fixed by
adding one to x/y when two fingers are on the same line vertically or
horizontally in the kernel. That happened around kernel 2.6.30 time frame.
except for the pad which is always in proximity and didn't rely on
multiplexing, so we could skip that.
PAD has a different story. It was not the proximity made the difference.
It was because we associated PAD events to a separate tool
(BTN_TOOL_FINGER).
To return BTN_TOOL_FINGER to single touch events, kernel merged PAD events
for Bamboo into touch events, which introduced a set of new problems in X
driver.
Ping
does this sound correct?
Cheers,
Peter
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.
--
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
Re: [Linuxwacom-devel] [PATCH 1/4] Remove channel duplication code for generic devices
On Thu, Dec 13, 2012 at 10:08:07PM -0800, Ping Cheng wrote:
On Thursday, December 13, 2012, Peter Hutterer 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.
You are right for the need of X driver code here. However, we updated
the kernel driver soon after we realized the issue. It was fixed by
adding one to x/y when two fingers are on the same line vertically or
horizontally in the kernel. That happened around kernel 2.6.30 time frame.
in my interest of course: the RHEL6 kernel is based on 2.6.32 and MT came
after that, how is this kernel affected?
Cheers,
Peter
except for the pad which is always in proximity and didn't rely on
multiplexing, so we could skip that.
PAD has a different story. It was not the proximity made the difference.
It was because we associated PAD events to a separate tool
(BTN_TOOL_FINGER).
To return BTN_TOOL_FINGER to single touch events, kernel merged PAD events
for Bamboo into touch events, which introduced a set of new problems in X
driver.
Ping
does this sound correct?
Cheers,
Peter
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.
Re: [Linuxwacom-devel] [PATCH 1/4] Remove channel duplication code for generic devices
On Thursday, December 13, 2012, Peter Hutterer wrote:
On Thu, Dec 13, 2012 at 10:08:07PM -0800, Ping Cheng wrote:
On Thursday, December 13, 2012, Peter Hutterer 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 javascript:;
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.
You are right for the need of X driver code here. However, we updated
the kernel driver soon after we realized the issue. It was fixed by
adding one to x/y when two fingers are on the same line vertically or
horizontally in the kernel. That happened around kernel 2.6.30 time
frame.
in my interest of course: the RHEL6 kernel is based on 2.6.32 and MT came
after that, how is this kernel affected?
The 2.6.32 kernel driver included in RHEL6 does not support Wacom 2FG touch
devices. In fact, RHEL6 does not support MT in any form. I had to make my
own drivers for my RHEL6 users to use Wacom MT devices...
We are crossing our fingers that RHEL7 will support MT :).
Ping
Cheers,
Peter
except for the pad which is always in proximity and didn't rely on
multiplexing, so we could skip that.
PAD has a different story. It was not the proximity made the difference.
It was because we associated PAD events to a separate tool
(BTN_TOOL_FINGER).
To return BTN_TOOL_FINGER to single touch events, kernel merged PAD
events
for Bamboo into touch events, which introduced a set of new problems in X
driver.
Ping
does this sound correct?
Cheers,
Peter
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;
--
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
Re: [Linuxwacom-devel] [PATCH 1/4] Remove channel duplication code for generic devices
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
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
--
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 1/4] Remove channel duplication code for generic devices
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
--
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 1/4] Remove channel duplication code for generic devices
It certainly doesn't hurt :) I think my biggest problem is that I never
really understood exactly when this code was required. 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.comwrote:
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
Re: [Linuxwacom-devel] [PATCH 1/4] Remove channel duplication code for generic devices
On Wed, Dec 12, 2012 at 10:54 AM, Jason Gerecke killert...@gmail.comwrote:
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...
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.comwrote:
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
[Linuxwacom-devel] [PATCH 1/4] Remove channel duplication code for generic devices
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
