search

espruino / Espruino

The Espruino JavaScript interpreter - Official Repo
http://www.espruino.com/
Other
2.74k stars 741 forks source link

Firmware v18.90 : Bangle2 Lock #2387

Closed d3nd3 closed 1 year ago

d3nd3 commented 1 year ago

I have noticed something odd occurring on the Bangle 2. Bangle.setLCDTimeout(0); in a boot file. ~The device becomes locked. This does not occur on the Bangle 1. I suppose its related to my recent code change? although I can't pinpoint the problem area. We know that B2 has a default lockTimeout of 5000 compared to 30000 for B1.~

~Thinking of a possibility that its some race condition, because didn't you say the PollHandler was interrupt based?~

~Struggling to reproduce, so its likely a race condition, can't confirm.~

Ok, now I see what is happening: The locked state is preserved across reloads. Put Bangle.setLCDTimeout(0); in boot file again. But now adjust locked state using Bangle.setLocked() on left hand side, you should see that the locked status is preserved across load() or reset().

Now I understand the cause of this, I'm not sure if its a bug or its wanted behaviour. Just took me by surprise.

d3nd3 commented 1 year ago

Well, false assumptions on my behalf, closing. This is intended behaviour. Just funny that it kind of bricks your device if you call it whilst its already locked. Putting an unlock in there might not hurt, but not super important either. If someone is using manual lock mode, they should have their own ways to unlock it laid out.

gfwilliams commented 1 year ago

Yes, so you're saying that with Bangle.setLCDTimeout(0) the device no longer unlocks itself on button presses?

As you say if you do that it's up to you to lock/unlock yourself - but just to confirm, do you see something different on Bangle.js 1? Or it's just that the longer timeout meant that it didn't happen to be locked when you called it?

d3nd3 commented 1 year ago

Ye same behaviour. Disregard my observations.