Skip to content

Conversation

@gmarull
Copy link
Member

@gmarull gmarull commented Feb 2, 2026

It's just useless. You just want to know if watch shake occurred, in any direction.

It's just useless. You just want to know if watch shake occurred, in any
direction.

Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
@gmarull gmarull requested a review from jplexer February 2, 2026 16:43
Copy link
Member

@jplexer jplexer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should do this. The AccelTapHandler callback signature includes axis and direction as parameters, and this is part of the public SDK API that app developers rely on. The developer documentation explicitly describes how axis tells you which axis the tap was detected along, and direction indicates positive (1) or negative (-1).
There are apps out there that use this information, for example, to distinguish between different tap orientations and trigger different behaviors depending on which way the watch was flicked. Removing this would break those apps or silently degrade their functionality.
Even if most use cases only care about "a shake happened," that doesn't mean the axis/direction info is useless for everyone.

@gmarull
Copy link
Member Author

gmarull commented Feb 2, 2026

I don't think we should do this. The AccelTapHandler callback signature includes axis and direction as parameters, and this is part of the public SDK API that app developers rely on. The developer documentation explicitly describes how axis tells you which axis the tap was detected along, and direction indicates positive (1) or negative (-1). There are apps out there that use this information, for example, to distinguish between different tap orientations and trigger different behaviors depending on which way the watch was flicked. Removing this would break those apps or silently degrade their functionality. Even if most use cases only care about "a shake happened," that doesn't mean the axis/direction info is useless for everyone.

Something in PebbleOS is actually broken, see:

void accel_tap_service_subscribe(AccelTapHandler handler) {
  AccelServiceState * session = accel_service_private_get_session(PebbleTask_Unknown);
  accel_session_shake_subscribe(session, handler);
}

So, tap means, in practice, subscribe to shake events. That's wrong. Our sensor can detect "motion", tap and double tap. We need to fix this...

Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
@gmarull gmarull added the DNM Do Not Merge label Feb 2, 2026
@gmarull
Copy link
Member Author

gmarull commented Feb 2, 2026

@jplexer see latest push for split

Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
@gmarull gmarull force-pushed the accel-shake-improve branch from 648f4e6 to 033792e Compare February 2, 2026 17:40
@jplexer
Copy link
Member

jplexer commented Feb 2, 2026

yeah thats better! We just gotta figure out how we do legacy apps that expect the axis at that callback

@gmarull
Copy link
Member Author

gmarull commented Feb 2, 2026

yeah thats better! We just gotta figure out how we do legacy apps that expect the axis at that callback

The shake API is actually a new one; tap is kept the same, but we now need to feed the event from the sensor.

@jplexer
Copy link
Member

jplexer commented Feb 2, 2026

oh haha I misread that!

@gmarull gmarull marked this pull request as draft February 12, 2026 11:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

DNM Do Not Merge

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants