You are reading a single comment by @d3nd3-o0 and its replies. Click here to read the full conversation.
  • I tested it a bit further.

     (function() {
      clearWatch();
      setWatch(() => {
        console.log("Rising/Pressed...");
      },BTN1,{repeat:true,edge:'rising',deboun­ce: 0});
      setWatch(() => {
        console.log("Falling/Released...");
      },BTN1,{repeat:true,edge:'falling',debou­nce: 0});
    })();
    
    
    Rising/Pressed...
    Rising/Pressed...
    Falling/Released...
    

    This is the output that seems to cause the issue. So imagine these sequence of events are handled by the firmware. The second time of 'pressed' :

    line 685 jswrap_bangle.c

    if (!lcdPowerOn && state) {
            bangleTasks |= JSBT_LCD_ON;
            lcdWakeButton = button;
            return; // don't push button event if the LCD is off
          }
    

    It won't return here, because lcdPowerOn is already On? So then it propagates this '2nd' press.

    line 1614 jswrap_bangle.c:

    if (bangleTasks & JSBT_LCD_ON) jswrap_banglejs_setLCDPower(1);
    

    which is part of function : jswrap_banglejs_idle
    which translates to : jswIdle() in line 2155 of jsinteractive.c

    So if the sequence is press -> press -> release or rising -> rising -> falling, I'm arguing that the second rising does get propagated because the function can't return because the lcdPowerOn variable is true. Its just a theory that seems probable.

    Temporary solution could be to move the screen turning on 'action' , to the keyUp event instead of KeyDown. This way the lcdPowerOn will not be true and those keyDowns can be properly consumed/blocked from propagating.

About

Avatar for d3nd3-o0 @d3nd3-o0 started