Backlight disable: Lua/UBASIC commands + power input measurement results - page 2 - General Discussion and Assistance - CHDK Forum

Backlight disable: Lua/UBASIC commands + power input measurement results

  • 18 Replies
  • 12850 Views
*

Offline barret

  • ***
  • 125
  • S3 & a550
Re: Backlight disable: Lua/UBASIC commands + power input measurement results
« Reply #10 on: 15 / January / 2009, 04:19:36 »
Advertisements
i just want to thank you for your work on this. i thought about it earlier, but didn't realise that it is possible to implement. :)
great job!

greets

*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Backlight disable: Lua/UBASIC commands + power input measurement results
« Reply #11 on: 15 / January / 2009, 14:15:17 »
- according to fudgey, it is not neccessary adding sigs to all 5 reference firmwares. i dont know which to remove though, trial and error? any hints?

Didn't try compiling (i.e. does it still find the same stubs if I do this), but:

if you take a look at signatures_vxworks.h, you'll find three signatures for the functions, one for each reference firmware, for example

static FuncSig func_sig_TurnOnBackLight_1[] = {
static FuncSig func_sig_TurnOnBackLight_2[] = {
static FuncSig func_sig_TurnOnBackLight_3[] = {

A quick comparison shows that _2 and _3 are pretty much equal, if not identical and _1 differs from those two. So TurnOnBackLight should be removed from sig_ref_vxworks_3.txt. TurnOffBacklight seems to differ slightly, but not much. If you see a lot of ALT stubs (and hopefully they matched the same address than the primary one) for that too it's probably for the best to remove it as well.

Similarly both dryos sigs look pretty much alike, especially for TurnOn* so there should be no need to have these in sig_ref_dryos_2.txt.

edit: added diff from make batch-zip with primaries in place and TurnO*Backlight added to vxworks sig ref 1 and 2 and dryos sig ref 1. Stubs for all subs found (I can't guarantee 100% correctness of course), all without ALT stubs. stubs_entry.S files for g9 subs 100d and 100g have probably been edited by someone because signature finder screws up those files entirely compared to trunk.
« Last Edit: 15 / January / 2009, 16:25:40 by fudgey »

*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX
Re: Backlight disable: Lua/UBASIC commands + power input measurement results
« Reply #12 on: 15 / January / 2009, 17:00:03 »
finally this baby is in trunk.

now we only need to discuss the use of this. does it make sense to loop the turnoff command in lua/ubasic so the display is immediately shut off after a shot? or should we integrate it in CHDK directly, so it is called in a given interval directly by a "screensaver watchdog"?

*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Backlight disable: Lua/UBASIC commands + power input measurement results
« Reply #13 on: 15 / January / 2009, 17:21:32 »
finally this baby is in trunk.

Yay! :D

now we only need to discuss the use of this. does it make sense to loop the turnoff command in lua/ubasic so the display is immediately shut off after a shot? or should we integrate it in CHDK directly, so it is called in a given interval directly by a "screensaver watchdog"?

For now I'm good with having to call it after shooting in scripts (e.g. in MD scripts it may be desirable to have backlight enabled during review, so the way it works now should at least be left as an option).

But if we want it to really stay dark outside scripts, more work needs to be done obviously. Calling the disable function periodically is probably not very smart (in terms of CPU efficiency), but we don't currently know a way to determine whether the lights are on or not, do we? So that leaves calling it sometime after each shoot and other things that enable backlight...?

btw, to prevent confusion: display is not shut off by these commands, this is only backlight control... LCD image is still there and updating, it's just really really dark.



Re: Backlight disable: Lua/UBASIC commands + power input measurement results
« Reply #14 on: 16 / January / 2009, 19:53:17 »
I just tried calling
set_backlight(0)
before
md_detect_motion(...)
in lua and find that the back light is not disabled.

set_backlight(0) works fine when I run metronom.lua.

Has anyone else tried this? I'm using an A620.

Thanks.

Re: Backlight disable: Lua/UBASIC commands + power input measurement results
« Reply #15 on: 17 / January / 2009, 03:21:32 »
In my old A80, there is a high speed continuous shooting mode that disables LCD when shooting. But I don't see this function in A650

*

Offline barret

  • ***
  • 125
  • S3 & a550
Re: Backlight disable: Lua/UBASIC commands + power input measurement results
« Reply #16 on: 17 / January / 2009, 05:51:49 »
Quote
In my old A80, there is a high speed continuous shooting mode that disables LCD when shooting. But I don't see this function in A650
disabling LCD is different from disabling backlight of LCD. Backlight disables only lighting of lcd, not the whole LCD (that can be done by pressing DISP button).

Re: Backlight disable: Lua/UBASIC commands + power input measurement results
« Reply #17 on: 18 / January / 2009, 07:00:42 »
finally this baby is in trunk.

now we only need to discuss the use of this. does it make sense to loop the turnoff command in lua/ubasic so the display is immediately shut off after a shot? or should we integrate it in CHDK directly, so it is called in a given interval directly by a "screensaver watchdog"?

Currently, to ensure that set_backlight(0) works on my A620 after a half-shoot or full-shoot, I need to sleep for at least 400ms after get_shooting() has returned false before calling set_backlight(0) so that the camera has had time to re-initialise the LCD display. Otherwise, the camera turns the back-light on again.

Therefore, I think a "screensaver watchdog" periodically checking a flag set by set_backlight() would be more convenient.


*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX
Re: Backlight disable: Lua/UBASIC commands + power input measurement results
« Reply #18 on: 18 / January / 2009, 14:42:09 »
yeah, that would definitly be nice. will think of a way to do it, not on the top priority though. reopened the ticket.

 

Related Topics