pruss
03-05-2006, 09:45 AM
I posted the following on Palm's developer forum. I would like to encourage you guys, if you have the problem, to write Palm and ask them for an OS patch, and tell them that (a) a patch should be possible, and (b) a patch was released in the past for a very similar problem (see below). Alex
SUMMARY:
The TX and T5 (and probably also the LifeDrive) have a digitizer noise problem on pen up. I develop a virtual keyboard product (myKbd ATOMIK, based on IBM's ATOMIK layout; see: www.zlthemes.com/Programs.php), so this is important to me. I'd like this report to get to the right person at Palm, because my experimentation indicates that the problem can be fixed (or workaround) with an OS patch. The problem affects built-in application as well as third-party applications.
END USER MANIFESTATIONS:
The pen-up noise problem degrades end-user experience in several ways:
(1) Mis-selection in menus and popup lists. You tap on one entry, but another menu entry gets selected because the noise point shifts the selection. This is particularly an issue with smaller fonts.
(2) Spurious command strokes and other spurious taps.
(3) Mis-recognition or failure to recognize taps in virtual keyboards. This problem seriously degrades MessagEaseST, but can also be observed in the standard QWERTY DIA keyboard. The problem occurred in the initial beta versions of my own myKbd system, but the current release has a software workaround (the source code to the workaround is available in my partial source release at handypalmstuff.sf.net).
(4) Graffiti recognition is generally not affected significantly, though some Palm users have claimed to see the noise points manifested as short lines at the ends of strokes.
DETAILS OF PROBLEM:
An informal survey of my beta testers shows that the problem is present in most, though apparently not all, TX units. The problem shows up most clearly in rapidly tapping in one place. On pen-up, the last point returned by the digitizer can be off by about 1/8 to 1/3 of an inch. This is most easily seen by running the MemoPad app, minimizing the DIA and tapping rapidly in the DIA area. Some of the taps get extended to short lines, running SW-NE.
I saved digitizer data using the HAL version of EvtGetPenNative() while tapping. Here is what I found. Occasionally (and not that rarely on my TX and T5--probably at least once in about five or ten taps when tapping rapidly) when tapping in the DIA area, the last one (TX) or one or two (T5) samples are corrupt, showing up to the NE of the correct location. Discarding the last three samples before pen up solves the problem completely or almost completely. Once I correctly implemented this in my virtual keyboard, I have had no complaints about misrecognition.
I still have the tap data I gathered and I would be happy to forward it to a Palm engineer together with my interpretation.
The apparent hardware cause is that while the pen is being lifted, data from the digitizer becomes invalid, but the OS or hardware is failing to recognize that the pen is being lifted.
OS PATCH POSSIBILITY:
This problem occurred in the past with the first backlit Pilots, though apparently in the context of pen-down rather than pen-up noise, and an OS patch was issued. See http://www.geocities.com/SiliconValley/Campus/9054/tapbuga.html
it seems the problem occurs in the T5 and TX solely on pen-up. The problem disappears when one discards the last three EvtGetPen*() samples before pen-up. A workaround would be to patch the OS to pre-fetch three or four additional pen samples before generating a penDown, penMove and penUp event. If one of these samples shows pen up, then all the samples can be assumed to be corrupt.
Implementing this correctly is a bit challenging as it requires some looking ahead before generating the event, and one would have to be careful to ensure that sensitivity is not lost, especially for rapid strokes. See resident.c in the partial myKbd source.
I've put a lot of time into this issue, and would be happy to work with Palm on possible fixes.
SUMMARY:
The TX and T5 (and probably also the LifeDrive) have a digitizer noise problem on pen up. I develop a virtual keyboard product (myKbd ATOMIK, based on IBM's ATOMIK layout; see: www.zlthemes.com/Programs.php), so this is important to me. I'd like this report to get to the right person at Palm, because my experimentation indicates that the problem can be fixed (or workaround) with an OS patch. The problem affects built-in application as well as third-party applications.
END USER MANIFESTATIONS:
The pen-up noise problem degrades end-user experience in several ways:
(1) Mis-selection in menus and popup lists. You tap on one entry, but another menu entry gets selected because the noise point shifts the selection. This is particularly an issue with smaller fonts.
(2) Spurious command strokes and other spurious taps.
(3) Mis-recognition or failure to recognize taps in virtual keyboards. This problem seriously degrades MessagEaseST, but can also be observed in the standard QWERTY DIA keyboard. The problem occurred in the initial beta versions of my own myKbd system, but the current release has a software workaround (the source code to the workaround is available in my partial source release at handypalmstuff.sf.net).
(4) Graffiti recognition is generally not affected significantly, though some Palm users have claimed to see the noise points manifested as short lines at the ends of strokes.
DETAILS OF PROBLEM:
An informal survey of my beta testers shows that the problem is present in most, though apparently not all, TX units. The problem shows up most clearly in rapidly tapping in one place. On pen-up, the last point returned by the digitizer can be off by about 1/8 to 1/3 of an inch. This is most easily seen by running the MemoPad app, minimizing the DIA and tapping rapidly in the DIA area. Some of the taps get extended to short lines, running SW-NE.
I saved digitizer data using the HAL version of EvtGetPenNative() while tapping. Here is what I found. Occasionally (and not that rarely on my TX and T5--probably at least once in about five or ten taps when tapping rapidly) when tapping in the DIA area, the last one (TX) or one or two (T5) samples are corrupt, showing up to the NE of the correct location. Discarding the last three samples before pen up solves the problem completely or almost completely. Once I correctly implemented this in my virtual keyboard, I have had no complaints about misrecognition.
I still have the tap data I gathered and I would be happy to forward it to a Palm engineer together with my interpretation.
The apparent hardware cause is that while the pen is being lifted, data from the digitizer becomes invalid, but the OS or hardware is failing to recognize that the pen is being lifted.
OS PATCH POSSIBILITY:
This problem occurred in the past with the first backlit Pilots, though apparently in the context of pen-down rather than pen-up noise, and an OS patch was issued. See http://www.geocities.com/SiliconValley/Campus/9054/tapbuga.html
it seems the problem occurs in the T5 and TX solely on pen-up. The problem disappears when one discards the last three EvtGetPen*() samples before pen-up. A workaround would be to patch the OS to pre-fetch three or four additional pen samples before generating a penDown, penMove and penUp event. If one of these samples shows pen up, then all the samples can be assumed to be corrupt.
Implementing this correctly is a bit challenging as it requires some looking ahead before generating the event, and one would have to be careful to ensure that sensitivity is not lost, especially for rapid strokes. See resident.c in the partial myKbd source.
I've put a lot of time into this issue, and would be happy to work with Palm on possible fixes.