A better(?) way to control display off - page 4 - General Discussion and Assistance - CHDK Forum  

A better(?) way to control display off

  • 81 Replies
  • 23288 Views
*

Offline lapser

  • *****
  • 1093
Re: A better(?) way to control display off
« Reply #30 on: 30 / August / 2013, 18:07:54 »
Advertisements
I do see LcdCon_StopLcdPeriodicalSetting and LcdCon_StartLcdPeriodicalSetting in the sx260 dump. These do not exist in the D10 dump. No idea what they do, but the names are suggestive of something that periodically does something with the lcd ;) Try at your own risk.
It was worth a try, but it didn't do anything.
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

*

Offline lapser

  • *****
  • 1093
Re: A better(?) way to control display off
« Reply #31 on: 01 / September / 2013, 12:56:53 »
Good news! I had the "review" time set to 2 seconds on the SX260, and set to 0 on the other cameras. When I set review time to 0, the SX260 no longer turns on between pictures. So the new method works on all 4 cameras.

I did some tests last night to see how much longer the battery lasts with the display off. I used 2 identical batteries, but battery #2 lasted significantly longer.

Battery Tests - event_proc method of turning off display
2 Second Shot Interval | 1 second fixed exposure, 100 ISO | Continuous drive mode

Camera      Display OFF       Display ON        Difference    (# of pictures | time)

SX260        2916 | 97 min     2453 | 82 min     463 | 15 min = 19% longer  -- Battery #1

D20            4043 | 135 min   3543 | 118 min    500 | 17 min = 14% longer  -- Battery #2
D20                                       3088 | 103 min     = 6% longer than SX260    -- Battery #1


Also, CHDK shell has check boxes for compiler options. I have the box to allow native Lua calls checked, which worked until the recent trunk update. reyalp just fixed the expire by default problem, but it appears other CHDK shell compiler options are still being overridden. Was that fixed too? Thanks.
[EDIT] Never mind. CHDK Shell unchecked OPT_FORCE_LUA_CALL_NATIVE for the new trunk. I guess I have to recheck it for every new trunk.

Since native calls were disabled, my script stopped with an error. The enable native calls menu option was now visible, and it worked after doing that.

I'll try changing set_backlight() to use the new method in C, using eventprocs from C. That way my custom builds won't require native calls. I'll also try to figure out how to set the record review to 0 in C and restore it when the script exits. When (or if) I get it working, I'll post a patch. Phil can then re-write it correctly if you want it in the trunk.

I do think it's worth it to keep the backlight (display?) off without flashing while taking pictures. I'm thinking you could use a small camera as a dashboard camera taking pictures in continuous mode as fast as possible, perhaps at lower resolution if space is a problem. Having the screen on is distracting in this situation, as well as for night photography. The moderate power saving is also nice.

Here's the script function I used for the tests:
Code: [Select]
blight=1 -- backlight on / current state
bldisp=true -- turn off display with eventproc if true
if call_event_proc('DispDev_EnableEventProc') == -1 then
  if call_event_proc('DispDev.Create') == -1 then
    bldisp=false -- must turn off display with set_backlight
  end
end -- end of initialization code
function backlight(bl) -- bl=0 off, 1 on, -1 toggle
  if(bl<0)then bl=bitxor(blight,1)  -- toggles 0 or 1
  elseif (bl>1)then bl=1 end
  if(bl==blight)then return end -- don't double set to current state
  blight=bl
  set_backlight(bl) -- also do the old way in case event_proc doesn't work
  if(bldisp)then
    if(bl==0)then call_event_proc('DispCon_TurnOffDisplay')
    else call_event_proc('DispCon_TurnOnDisplay') end
  end
end
« Last Edit: 01 / September / 2013, 15:32:53 by lapser »
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

*

Offline reyalp

  • ******
  • 12887
Re: A better(?) way to control display off
« Reply #32 on: 01 / September / 2013, 14:55:50 »
Good news! I had the "review" time set to 2 seconds on the SX260, and set to 0 on the other cameras. When I set review time to 0, the SX260 no longer turns on between pictures. So the new method works on all 4 cameras.
Great, makes sense that review would turn the display back on.  I've confirmed this is true of D10 as well.

Quote
Also, CHDK shell has check boxes for compiler options. I have the box to allow native Lua calls checked, which worked until the recent trunk update. reyalp just fixed the expire by default problem, but it appears other CHDK shell compiler options are still being overridden. Was that fixed too? Thanks.
Looks like my last "fix" still confused CHDKSHELL. I think MSL fixed it for real now.
Don't forget what the H stands for.

*

Offline lapser

  • *****
  • 1093
Re: A better(?) way to control display off
« Reply #33 on: 01 / September / 2013, 15:45:26 »
Looks like my last "fix" still confused CHDKSHELL. I think MSL fixed it for real now.
I may be the only one confused. CHDK Shell unchecked the Lua native call option between builds. Is it supposed to stay checked?

The main problem with CHDK Shell is that it stays stuck on my last 1.2 build. It won't update to the new 1.3 builds. So I need to change the trunk every time I start CHDK Shell. A big problem with this is that every time CHDK Shell starts, it thinks there's a new trunk, if you have the Internet check on. Then, it downloads the new trunk again even it's the same trunk it downloaded before, i.e. you start CHDK Shell twice in one day.

The worst thing is that it when it re-downloads the trunk, it overwrites the trunk that it already downloaded without warning. So if you worked on that trunk, all your changes are lost. There needs to be a check before overwriting. I work around it by keeping Internet checking off, and backing up before turning it on. Maybe MSL fixed that already too?

[EDIT] Never mind again!   :-[  I updated to 3.44 and this problem appears to have been fixed. I thought I was doing auto updates. I'm good at finding bugs that have already been fixed!
« Last Edit: 01 / September / 2013, 16:27:03 by lapser »
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos


Re: A better(?) way to control display off
« Reply #34 on: 01 / September / 2013, 16:04:13 »
Looks like my last "fix" still confused CHDKSHELL. I think MSL fixed it for real now.
I may be the only one confused. CHDK Shell unchecked the Lua native call option between builds. Is it supposed to stay checked?

The main problem with CHDK Shell is that it stays stuck on my last 1.2 build. It won't update to the new 1.3 builds. So I need to change the trunk every time I start CHDK Shell. A big problem with this is that every time CHDK Shell starts, it thinks there's a new trunk, if you have the Internet check on. Then, it downloads the new trunk again even it's the same trunk it downloaded before, i.e. you start CHDK Shell twice in one day.

The worst thing is that it when it re-downloads the trunk, it overwrites the trunk that it already downloaded without warning. So if you worked on that trunk, all your changes are lost. There needs to be a check before overwriting. I work around it by keeping Internet checking off, and backing up before turning it on. Maybe MSL fixed that already too?
Using the build environment provided by CHDKshell,  TortoiseSVN, and a command prompt window with a couple of simple batch files takes a little bit to setup.  But once you have that done you will probably never run CHDKshell again.  I know I haven't (when I'm not using Linux in the first place).
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 12887
Re: A better(?) way to control display off
« Reply #35 on: 01 / September / 2013, 16:10:42 »
I may be the only one confused. CHDK Shell unchecked the Lua native call option between builds. Is it supposed to stay checked?
See http://trac.assembla.com/chdk/changeset/3060/trunk

Quote
The main problem with CHDK Shell is that it stays stuck on my last 1.2 build. It won't update to the new 1.3 builds. So I need to change the trunk every time I start CHDK Shell. A big problem with this is that every time CHDK Shell starts, it thinks there's a new trunk, if you have the Internet check on. Then, it downloads the new trunk again even it's the same trunk it downloaded before, i.e. you start CHDK Shell twice in one day.
I don't use or maintain chdkshell. That doesn't sound like correct behavior, but I'm not totally clear how it is supposed to work. Maybe you need to update the chdkshell program.

I just use the windows toolchain that comes with it and build make in a mingw bash shell. When I fired it up to check the expire problem, it correctly used the trunk rather than release branch, and downloaded each version into a directory.

The CHDKShell method of downloading copies of the source rather than working with SVN checkouts is not really great for people who want to do active development. Someone like you who is making significant changes to the source and wanting to keep up to date with development should be using SVN working copies.
Don't forget what the H stands for.

*

Offline msl

  • *****
  • 1274
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: A better(?) way to control display off
« Reply #36 on: 01 / September / 2013, 16:13:29 »
I may be the only one confused. CHDK Shell unchecked the Lua native call option between builds. Is it supposed to stay checked?
The CHDK Shell creates for every new revision a new localbuildconf.inc. That means, you must choose your build options again. Or you copy the localbuildconf.inc.

In case of the other problems you should clean up your configuration for the shell. Maybe it's helpful to delete the ini file.

For me the shell works fine after the fix in rev. 3060.

msl
CHDK-DE:  CHDK-DE links

*

Offline lapser

  • *****
  • 1093
Re: A better(?) way to control display off
« Reply #37 on: 01 / September / 2013, 16:34:39 »
The CHDK Shell creates for every new revision a new localbuildconf.inc. That means, you must choose your build options again. Or you copy the localbuildconf.inc.

In case of the other problems you should clean up your configuration for the shell. Maybe it's helpful to delete the ini file.

For me the shell works fine after the fix in rev. 3060.
Thanks for that info. I create a .diff file of all my mods every time I change trunks. The changes to localbuildconf.inc were part of the diff, so it was carrying my compiler options forward.

I also finally updated to 3.44 and the other problem has gone away (see [EDIT] above). I always say that you haven't found the real problem unless you feel like an idiot. I'm finding a lot of real problems lately!
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos


*

Offline lapser

  • *****
  • 1093
Re: A better(?) way to control display off
« Reply #38 on: 01 / September / 2013, 20:11:26 »
You can call eventprocs from C code with call_func_ptr(_ExecuteEventProcedure) or by calling _ExecuteEventProcedure directly if you are in arm code.
Can you tell me how I would call the specific event procs for the display on/off here? I see this in Luascript.c

call_func_ptr(_ExecuteEventProcedure,argbuf,n_args);

Since there are no numerical arguments to the display on/off, and registration functions, would they be called like this?

int result=call_func_ptr(_ExecuteEventProcedure,"DispCon_TurnOffDisplay",1);

Or does it have to be done like in gui.c for the romlog?

    unsigned args[1];
    args[0] = (unsigned)"DispCon_TurnOffDisplay;
    if (call_func_ptr(_ExecuteEventProcedure,args,1) == -1)


EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

*

Offline reyalp

  • ******
  • 12887
Re: A better(?) way to control display off
« Reply #39 on: 01 / September / 2013, 22:16:34 »
Or does it have to be done like in gui.c for the romlog?
Yes, that's how it works. It takes all the argument in an array, followed by the number of arguments. This is done to allow a variable number of arguments to pass through the thumb/arm transition (plus lua needs to be able to push a variable number at run-time)

Note the normal way to add a function to C is to add it to stubs_entry (via the finsig) or stubs_entry_2.s (manually) and then add a wrapper to generic/wrappers.c

For dryos cameras, these are already found (see funcs_by_*.csv) so it would just be a matter of updating it to appear in stubs_entry.S
Don't forget what the H stands for.

 

Related Topics