wait_click() with short timeout - page 3 - General Discussion and Assistance - CHDK Forum supplierdeeply

wait_click() with short timeout

  • 40 Replies
  • 7262 Views
*

Offline lapser

  • *****
  • 1093
Re: wait_click() with short timeout
« Reply #20 on: 28 / February / 2013, 13:48:16 »
Advertisements
There is another issue with wait_click().
Try the example script. All keys are fine with the exception of half_shot. I miss the drawings.
Try using "is_key(..) instead of "is_pressed(..)"

iskey() tests the last clicked key.    is_pressed() tests if the key is currently being pressed.

As Phil noted above, "shoot_half" is used as a modifier outside of scripts, so this may have something to do with it.
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

*

Offline msl

  • *****
  • 1269
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: wait_click() with short timeout
« Reply #21 on: 28 / February / 2013, 14:29:27 »
Try using "is_key(..) instead of "is_pressed(..)"

That does not help, the same error as described.

msl
CHDK-DE:  CHDK-DE links

*

Offline lapser

  • *****
  • 1093
Re: wait_click() with short timeout
« Reply #22 on: 28 / February / 2013, 14:57:21 »
That does not help, the same error as described.
I tested your script with build 2604 and shoot_half works for me. I'm using CHDK 2604 version. Maybe you can try the latest CHDK and see if it works on your camera? The wait_click changes are in the trunk now.
« Last Edit: 28 / February / 2013, 15:09:24 by lapser »
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

*

Offline msl

  • *****
  • 1269
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: wait_click() with short timeout
« Reply #23 on: 28 / February / 2013, 15:50:59 »
Thanks for your patience. I have found the cause. Both (is_key & is_pressed) run very well, when I start the script with the camera.

The described problem appears when I start the script via chdkptp - very strange.

msl
CHDK-DE:  CHDK-DE links


*

Offline lapser

  • *****
  • 1093
Re: wait_click() with short timeout
« Reply #24 on: 28 / February / 2013, 19:18:51 »
Thanks for your patience. I have found the cause. Both (is_key & is_pressed) run very well, when I start the script with the camera.

The described problem appears when I start the script via chdkptp - very strange.
That's interesting. "shoot_half" is used as a modifier when a script isn't running. I wonder if the script running flag is set properly when you start a script from chdkptp? Another possibility is that the code in kbd.c that decides if "shoot_half" is a modifier or a click is fooled by chdkptp.
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

*

Offline philmoz

  • *****
  • 3155
    • Photos
Re: wait_click() with short timeout
« Reply #25 on: 01 / March / 2013, 17:15:33 »
The wait_click changes broke existing scripts that used wait_click(0).

I've fixed this in revision 2607; but this now means that wait_click(0) waits for 1 day rather than return immediately if no key is pressed.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)

Re: wait_click() with short timeout
« Reply #26 on: 01 / March / 2013, 18:01:35 »
The wait_click changes broke existing scripts that used wait_click(0).
I've fixed this in revision 2607; but this now means that wait_click(0) waits for 1 day rather than return immediately if no key is pressed.
Easy enough to fix in a script - unless the value is derived through a calculation and then it could be a nasty surprise.

No way to have it just return like it used to ?
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline philmoz

  • *****
  • 3155
    • Photos
Re: wait_click() with short timeout
« Reply #27 on: 01 / March / 2013, 18:54:32 »
The wait_click changes broke existing scripts that used wait_click(0).
I've fixed this in revision 2607; but this now means that wait_click(0) waits for 1 day rather than return immediately if no key is pressed.
Easy enough to fix in a script - unless the value is derived through a calculation and then it could be a nasty surprise.

No way to have it just return like it used to ?


Since we can't fix every script I think it's better to keep the old logic so they don't break.

A new function that does what wait_click does; but without any waiting, could be added if this is really needed.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)


*

Offline lapser

  • *****
  • 1093
Re: wait_click() with short timeout
« Reply #28 on: 02 / March / 2013, 00:48:25 »
Since we can't fix every script I think it's better to keep the old logic so they don't break.
You could set it up so wait_click(1) returns immediately, i.e converts to 0 delay.
Quote
A new function that does what wait_click does; but without any waiting, could be added if this is really needed.
I'm planning to experiment with adding a keyboard buffer soon, accessed by a function like "get_key()".

I've noticed that the new wait_click() still misses keys when the script doesn't yield. When taking pictures rapidly, around 2 shots per second, my script sometimes blocks writing the log to the sd card because it's competing with the camera saving jpg files. If I press a key during this time, it can be missed.

What happens when a lua script doesn't yield? How is it interrupted? If it's blocked writing, I assume it's in a camera routine, and not in Lua, so does that mean it can't be interrupted?

Let's say lua calls a C routine that does msleep(1000). Does that mean the keyboard isn't polled for 1 second? Would it be better to poll the keyboard from a thread that isn't also running scripts, or run scripts in their own thread?
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

*

Offline reyalp

  • ******
  • 12537
Re: wait_click() with short timeout
« Reply #29 on: 02 / March / 2013, 02:56:51 »
What happens when a lua script doesn't yield? How is it interrupted? If it's blocked writing, I assume it's in a camera routine, and not in Lua, so does that mean it can't be interrupted?
I don't really understand what you mean hear. The OSes are preemptive, though the details aren't terribly clear (to me, at least)

Quote
Let's say lua calls a C routine that does msleep(1000). Does that mean the keyboard isn't polled for 1 second?
Yes, that would hang the firmwares keyboard task for one second, which would be bad. That's why the action stack exists.
Quote
Would it be better to poll the keyboard from a thread that isn't also running scripts, or run scripts in their own thread?
kbd_task replaces and extends the original firmware PhySw task, so making it not poll the keyboard wouldn't make any sense. Running script in it's own task would make sense, but would be a major architectural change. (edit: brief discussion of that here http://chdk.setepontos.com/index.php?topic=7611.msg81059#msg81059)
« Last Edit: 02 / March / 2013, 02:58:38 by reyalp »
Don't forget what the H stands for.

 

Related Topics