A better(?) way to control display off

lapser

1093

Re: A better(?) way to control display off

« Reply #30 on: 30 / August / 2013, 18:07:54 »

Advertisements

Quote from: reyalp on 30 / August / 2013, 15:30:44

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.

Logged

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

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 »

Logged

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

reyalp

14080

Re: A better(?) way to control display off

« Reply #32 on: 01 / September / 2013, 14:55:50 »

Quote from: lapser 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.

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.

Logged

Don't forget what the H stands for.

lapser

1093

Re: A better(?) way to control display off

« Reply #33 on: 01 / September / 2013, 15:45:26 »

Quote from: reyalp on 01 / September / 2013, 14:55:50

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 »

Logged

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

waterwingz

12138

Re: A better(?) way to control display off

« Reply #34 on: 01 / September / 2013, 16:04:13 »

Quote from: lapser on 01 / September / 2013, 15:45:26

Quote from: reyalp on 01 / September / 2013, 14:55:50
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).

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

14080

Re: A better(?) way to control display off

« Reply #35 on: 01 / September / 2013, 16:10:42 »

Quote from: lapser on 01 / September / 2013, 15:45:26

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.

Logged

Don't forget what the H stands for.

msl

1280
A720 IS, SX220 HS 1.01a

Re: A better(?) way to control display off

« Reply #36 on: 01 / September / 2013, 16:13:29 »

Quote from: lapser on 01 / September / 2013, 15:45:26

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

Logged

CHDK-DE: CHDK-DE links

lapser

1093

Re: A better(?) way to control display off

« Reply #37 on: 01 / September / 2013, 16:34:39 »

Quote from: msl on 01 / September / 2013, 16:13:29

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!

Logged

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

lapser

1093

Re: A better(?) way to control display off

« Reply #38 on: 01 / September / 2013, 20:11:26 »

Quote from: reyalp on 30 / August / 2013, 16:44:47

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)

Logged

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

reyalp

14080

Re: A better(?) way to control display off

« Reply #39 on: 01 / September / 2013, 22:16:34 »

Quote from: lapser on 01 / September / 2013, 20:11:26

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

Logged

Don't forget what the H stands for.