A better(?) way to control display off - page 3 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 2 [3] 4 5 6 7 8 9   Go Down

A better(?) way to control display off

  • 81 Replies
  • 45494 Views
*

Offline srsa_4c

  • ******
  • 4451
Re: A better(?) way to control display off
« Reply #20 on: 25 / August / 2013, 08:53:55 »
Advertisements
Quote from: msl on 25 / August / 2013, 06:41:39
It's a pain to test scripts without this. When I use a PTP connection for script test (e.g. hostlua) it is difficult everytime to activate 'native calls' via CHDK menu.
You can still define OPT_FORCE_LUA_CALL_NATIVE in localbuildconf.inc .
Quote
I think a CHDK script author should have the responsibility and not CHDK in such cases.
We can't control scripts showing up in various places on the internet. Sure, it's highly unlikely that anybody would bother writing such a malicious script, but it's possible. At least those won't work without user consent on "official" CHDK builds.
Logged
*

Offline lapser

  • *****
  • 1093
Re: A better(?) way to control display off
« Reply #21 on: 25 / August / 2013, 13:35:41 »
Quote from: srsa_4c on 25 / August / 2013, 08:53:55
You can still define OPT_FORCE_LUA_CALL_NATIVE in localbuildconf.inc .
OK, that explains why I don't see it in the CHDK menu. I forgot I have this compile option checked in CHDK Shell.

So to generalize the new backlight (display) off method to work without native calls, I guess we need to add it to the sig finder or something? I still don't see anything wrong with just changing set_backlight() to do both. That way, it would work with older scripts.  Also, the option to toggle the backlight with set_backlight(-1) would be very convenient for scripts to use. I'd love to code it if Phil or someone adds it to the sig finder.

I set up the SX50 and G1X to catch the sunset and ISS flyover last night. The new display off function worked great! After it gets dark, it's really nice not to have the display screen on or flashing and messing up your night vision. I'll have to try a battery drain test, with display off, soon.
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline reyalp

  • ******
  • 14137
Re: A better(?) way to control display off
« Reply #22 on: 25 / August / 2013, 14:42:35 »
Quote from: msl on 25 / August / 2013, 08:07:31
Related to 'native calls' I know only one incident. That was reyalp's 'small accident' with the factory mode. With CHDK-DE we had this feature activated as default. There were no problems for years.
My incident was not malicious, just pebkac ;)

It would be pretty easy to modify one of the scripts posted on the wiki to have, e.g.  EraseSectorOfRom in it somewhere. People could easily completely brick their cameras before we figured out what was going on.

Of course there are still ways you could do that without native calls, but it would be a lot trickier to make it generic.
Logged
Don't forget what the H stands for.
*

Offline msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: A better(?) way to control display off
« Reply #23 on: 25 / August / 2013, 15:48:48 »
Quote from: reyalp on 25 / August / 2013, 14:42:35
My incident was not malicious, just pebkac ;)

It would be pretty easy to modify one of the scripts posted on the wiki to have, e.g.  EraseSectorOfRom in it somewhere. People could easily completely brick their cameras before we figured out what was going on.
I didn't say that it was malicious code. I wrote it was a 'small accident'.

We can not protect us against all eventualities. In this case you must e.g. also disable the set_zoom() function, because you could provoke a lens error. That would be easier as a 'native calls' command.

But at this point we can close this offtopic discussion. I have a solution for 'my problem'.

msl
Logged
CHDK-DE:  CHDK-DE links
*

Offline lapser

  • *****
  • 1093
Re: A better(?) way to control display off
« Reply #24 on: 28 / August / 2013, 20:06:26 »
Getting back to the original topic (thanks for the native calls info), I added the Lua code described in my previous post and it worked great on the G1X, SX50 and D20!
http://chdk.setepontos.com/index.php?topic=10551.msg104446#msg104446

Unfortunately, on the SX260, the new code behaves just like the old set_backlight(0). That is, the screen goes blank until you take a picture, and then it comes back on. I wonder if it's a problem in the port? Or maybe Canon used the same backlight code for the function called by the eventproc and by set_backlight?

Maybe one of the expert hackers could take a look at the SX260 101a code for me and see if you can figure out the reason for this behavior? I can just use the old set_backlight for now, but it flashes as we know.

If you put the camera in continuous drive mode and run this script, it should demonstrate the problem, or lack of a problem, on different cameras. The screen should toggle on and off every time you press a key.

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
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
  if(bldisp)then
    if(bl==0)then call_event_proc('DispCon_TurnOffDisplay')
    else call_event_proc('DispCon_TurnOnDisplay') end
  else
    set_backlight(bl) -- do the old way if no event_proc available
  end
end

function restore()
  backlight(1)
end

press("shoot_full") -- in continuous mode
repeat
    wait_click()
    backlight(-1) -- toggle
until is_key("menu")
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline reyalp

  • ******
  • 14137
Re: A better(?) way to control display off
« Reply #25 on: 28 / August / 2013, 21:43:53 »
Quote from: lapser on 28 / August / 2013, 20:06:26
I wonder if it's a problem in the port?
No. calling eventprocs is calling the canon firmware directly, it has nothing to do with the port. If you are successfully making the same calls and the effect is different, then the firmware is behaving differently.

Quote
Or maybe Canon used the same backlight code for the function called by the eventproc and by set_backlight?
No, display off is not the same a set backlight.

You could try:
call_event_proc('LcdCon_SetLcdBackLightBrightness',0)
On my cameras, this also did not get reset after shooting.


Logged
Don't forget what the H stands for.
*

Offline lapser

  • *****
  • 1093
Re: A better(?) way to control display off
« Reply #26 on: 30 / August / 2013, 13:13:21 »
Quote from: reyalp on 28 / August / 2013, 21:43:53
You could try:
call_event_proc('LcdCon_SetLcdBackLightBrightness',0)
On my cameras, this also did not get reset after shooting.
Thanks for the suggestion. I only tested it on the SX260, but it just turns the brightness all the way up. I tried it 3 ways with the same result:

call_event_proc('LcdCon_SetLcdBackLightBrightness',0)
call_event_proc('LcdCon_SetLcdBackLightBrightness',1)
bl=1
call_event_proc('LcdCon_SetLcdBackLightBrightness',bl)

Is this the right way to call the event_proc with a parameter? I wonder if the format of the parameter is correct? Thanks again.
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline reyalp

  • ******
  • 14137
Re: A better(?) way to control display off
« Reply #27 on: 30 / August / 2013, 15:30:44 »
Quote from: lapser on 30 / August / 2013, 13:13:21
Thanks for the suggestion. I only tested it on the SX260, but it just turns the brightness all the way up. I tried it 3 ways with the same result:
On my cameras, the value seems to be %, 0-100

Quote
Is this the right way to call the event_proc with a parameter? I wonder if the format of the parameter is correct? Thanks again.
Yes,
Code: [Select]
call_event_proc('LcdCon_SetLcdBackLightBrightness',0)
etc. is correct.

I tend to test this kind of thing using chdkptp:
con 4> =return call_event_proc('LcdCon_SetLcdBackLightBrightness',75)
5:return:0

The return 0 tells me that the eventproc is actually registered. If the eventproc isn't known, it will be -1.

Maybe sx260 is just different... it's unsurprising that there is variation between Canon models. This is a good reason not to try to unify all the different methods in set_backlight(), what works well on one camera may not work well on others, and we have no way to verify them all. If we expose the different methods, people can at least try to find one that works for their situation.

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.
Logged
Don't forget what the H stands for.
*

Offline lapser

  • *****
  • 1093
Re: A better(?) way to control display off
« Reply #28 on: 30 / August / 2013, 16:07:04 »
Quote from: reyalp on 30 / August / 2013, 15:30:44
Maybe sx260 is just different... it's unsurprising that there is variation between Canon models. This is a good reason not to try to unify all the different methods in set_backlight(), what works well on one camera may not work well on others, and we have no way to verify them all. If we expose the different methods, people can at least try to find one that works for their situation.
Yes, I think we should do it with event_proc in Lua for now. If we can get it working well on all or most cameras, it might be worth putting something in the trunk.
Quote
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.
Thanks, I'll give it a try. Maybe it will work in combination with set_backlight(0) or something.

What happens if I call these eventprocs on a camera that doesn't have them? I just get a return value of 0, with no action?

How about if I call a function like TurnBacklightOff() in C but it's not in the sig finder? Does that just return without doing anything?

Will you explain what your two initialization statements are doing? I'm not clear on how event_proc works. Thanks.

if call_event_proc('DispDev_EnableEventProc') == -1 then
  if call_event_proc('DispDev.Create') == -1 then
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline reyalp

  • ******
  • 14137
Re: A better(?) way to control display off
« Reply #29 on: 30 / August / 2013, 16:44:47 »
Quote from: lapser on 30 / August / 2013, 16:07:04
What happens if I call these eventprocs on a camera that doesn't have them? I just get a return value of 0, with no action?
It returns -1, with no action. Note that it is possible for the eventproc itself to return -1 for other reasons so this doesn't definitively tell you if the eventproc is known or not. Many of the functions return -1 if there is some other error, such as an invalid parameter.
Quote
How about if I call a function like TurnBacklightOff() in C but it's not in the sig finder? Does that just return without doing anything?
I don't really understand. If you try to call an unknown function from C, you won't be able to compile. Note that DispCon_TurnOffBackLight / DispCon_TurnOnBackLight should be equivalent (or very similar) to TurnBacklightOff / TurnBacklightOn.

You can call eventprocs from C code with call_func_ptr(_ExecuteEventProcedure) or by calling _ExecuteEventProcedure directly if you are in arm code.

You can call random addresses as functions from lua with call_func_ptr()

Quote
Will you explain what your two initialization statements are doing? I'm not clear on how event_proc works. Thanks.

if call_event_proc('DispDev_EnableEventProc') == -1 then
  if call_event_proc('DispDev.Create') == -1 then
call_event_proc (known as ExecuteEventProcedure in the canon firmware) can only execute eventprocs that are registered. Many eventprocs are grouped into "libraries" that are registered by other event procedures. Over time, Canon has changed the names of some of these registration eventproces.

So the code above tries to call DispDev_EnableEventProc, and if the return value is -1 (normally returned for an unknown event proc) it tries to call DispDev.Create.
Logged
Don't forget what the H stands for.
Pages: 1 2 [3] 4 5 6 7 8 9   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal