haptic: Use event configuration based haptic event type detection #45
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| */ | ||
| #define HAPTIC_TYPE_KEY "haptic.type" | ||
|
|
||
| /* Convinience macros for supported haptic types */ |
|
Some minor comments, please have a look. Other than that, looks good. Is there also a PR for the droid vibrator plugin? |
|
The droid vibrator plugin will work as it is now. No changes needed there. |
The ffmemless plugin was using effect configuration based *_TOUCH key to detect if effect is touch interaction related to filter it out in case touch haptics is disabled from profile. This got broken when the can_handle policy was moved to haptic.c. And also it was never working for android vibrator plugin. Fixed the touch haptic detection by replacing the ffmemless specific key with a event configuration based "haptic.type" key that will apply right policy to all vibra plugins utilizing n_haptic_can_handle function. The haptic.key currently supports type strings "alarm" and "touch". This may be appended in the future if there is some need. Currently default policy does not block haptic playback if "haptic.type" key is missing for event, but it may be used for that in the future to for example move the call state handling from haptic.c to event configuration files, like it's done for audio now. Signed-off-by: Kalle Jokiniemi <kalle.jokiniemi@jolla.com>
|
Previous commented issues fixed now. |
|
LGTM. |
kjokinie
pushed a commit
that referenced
this pull request
Jul 23, 2014
haptic: Use event configuration based haptic event type detection
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The ffmemless plugin was using effect configuration based *_TOUCH key
to detect if effect is touch interaction related to filter it out
in case touch haptics is disabled from profile. This got broken when
the can_handle policy was moved to haptic.c. And also it was never
working for android vibrator plugin.
Fixed the touch haptic detection by replacing the ffmemless specific
key with a event configuration based "haptic.type" key that will apply
right policy to all vibra plugins utilizing n_haptic_can_handle function.
The haptic.key currently supports type strings "alarm" and "touch". This
may be appended in the future if there is some need.
Currently default policy does not block haptic playback if "haptic.type"
key is missing for event, but it may be used for that in the future to
for example move the call state handling from haptic.c to event
configuration files, like it's done for audio now.
Signed-off-by: Kalle Jokiniemi kalle.jokiniemi@jolla.com