Resources | Resources |



FASTAP support

Integration of support for FASTAP is in accordance with expanding keypad support for QWERTY keypads.

FASTAP is a keypad technology and driver that can detect and surmise what keys are pressed. Specifically, FASTAP has the concept of raised keys and low keys that are alternately placed on the keypad. Though high keys or raised keys can be easily pressed without error, the user can easily hit some high keys while intending to press the low keys.

FASTAP has three algorithms in its driver to correct this possibility:

  • Low keys always take priority over high keys. For example, if a low key and one or two high keys are pressed at the same time, the driver interprets that as a low key press.
  • If a user presses diagonal high keys (each low key is surrounded by 4 high keys in a square), then this is also interpreted by the driver as a low key press, even though the low key was not actually hit.
  • If a high key is pressed and a low key is pressed while the high key is still pressed, the keypad interprets this as a low key press.

This third point cannot be integrated with Brew MP, because, in the default driver behavior, if the delay is sufficiently small (less than 160 ms), then the driver just sends one event: the event for the low key (the high key press is ignored). However, if the delay is more than 160 ms (a high key is pressed and a low key is pressed with it, but the low key was pressed late), the driver sends out the high key press after 160 ms, and then, when it sees the low key press, it sends out a key delete event for the high key, followed by the key down event for the low key. Brew MP does not have a concept of a key delete event, so the approach for FASTAP is:

  1. The interaction between the driver and the OEM porting layer is the same as it is between, for example, the HS and UI tasks for normal keypads. The OEM layer gets key_down and key_up events and calls AEE_Event for EVT_KEY_PRESS, EVT_KEY, EVT_KEY_RELEASE as before. For QWERTY keys, the mapping is determined as described in the Standardizing key events topic.
  2. For the key cancel event, there is no equivalent. So, Brew MP gives two events to the application: the EVT_KEY event for the (mistaken) high key followed by the EVT_KEY event for the low key that was actually intended. So, users will end up thinking that they hit the wrong key (which they did; however, a FASTAP correction could not be applied), and will correct the key.

    Note: This is expected to be a rare occurrence.

  3. For the wrong key, FASTAP gives key_down followed by key_delete (not key_up). So the key_delete must be interpreted as a key_release, and an EVT_KEY_RELEASE must be sent for the high key. Therefore, the OEM should call AEE_Event with EVT_KEY_RELEASE for the key_delete event from the FASTAP driver.