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

A better(?) way to control display off

  • 81 Replies
  • 22585 Views
*

Offline reyalp

  • ******
  • 12690
A better(?) way to control display off
« on: 14 / August / 2013, 01:06:06 »
Advertisements
While looking at the backlight off patch waterwingz posted in http://chdk.setepontos.com/index.php?topic=8997.msg104053#msg104053 I decided to take a look for cleaner option.

On my cameras, the following eventprocs turn off and on the display completely, and stay in effect after shooting. MF remains enabled through an off / on cycle (unlike normal display off on a540, which kills the MF setting) AFL also stays in effect. You can also turn of the display in play mode, which is not normally possible. The live view remains active, so this will not have the battery saving of the modes that turn the sensor off. It's more like the video plug trick.

DispCon_TurnOffDisplay
DispCon_TurnOnDisplay

The registration function for A540  is DispDev_EnableEventProc. On D10 it can also be registered with DispDev.Create (I assume on later cameras only DispDev.Create works)

D10 does not have a native display off mode. I'd like to know if it works on other cameras like this, and whether anyone sees any side effects.

Issues I've seen so far:
- Switching between rec and play with the display off seems to crash.
- if you turn the display off and on in play mode, the review picture is no longer visible. Switching images makes it show again.
- the bitmap ui overlay (both chdk and canon) may not display after turning on, until you do something that causes the canon firmware to refresh it.

Assuming this works widely, I think we should add it as a standard script function so people don't have to enable native calls.

I also found that LcdCon_SetLcdBackLightBrightness stays in effect after shooting. It appears to accept values between 0 (off) and 100. 1 is darker than the range allowed in the canon menu, and I think 100 is slightly brighter.

To use this in Lua, the following should work with native calls enabled

Code: [Select]
if call_event_proc'DispDev_EnableEventProc' == -1 then
 if call_event_proc'DispDev.Create' == -1 then
  error'eventprocs not found'
 end
end

call_event_proc'DispCon_TurnOffDisplay'
-- do whatever you want to do while the display is off
call_event_proc'DispCon_TurnOnDisplay'
Not that if your script ends with the display off, you may need to reboot to get it back on. On cameras that have a native display off mode, cycling through that should get it back.

edit:
Some related eventprocs are listed here http://chdk.wikia.com/wiki/User:ReyalP/EventProcNotes#DispDev_EnableEventProc
« Last Edit: 14 / August / 2013, 01:13:08 by reyalp »
Don't forget what the H stands for.

Re: A better(?) way to control display off
« Reply #1 on: 14 / August / 2013, 10:30:43 »
Confirmed on s2 is. Registration is through DispDev_EnableEventProc.

You forgot parenthese :) The correct syntax for others:

Code: [Select]
if call_event_proc('DispDev_EnableEventProc') == -1 then
 if call_event_proc('DispDev.Create') == -1 then
  error('eventprocs not found')
 end
end

call_event_proc('DispCon_TurnOffDisplay')
-- do whatever you want to do while the display is off
call_event_proc('DispCon_TurnOnDisplay')
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick

Re: A better(?) way to control display off
« Reply #2 on: 14 / August / 2013, 14:45:17 »
The live view remains active, so this will not have the battery saving of the modes that turn the sensor off.
So it should be better than just turning off the backlight but not as good as using the DISP key to turn off the display in cams with an OVF ?
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 12690
Re: A better(?) way to control display off
« Reply #3 on: 14 / August / 2013, 16:11:27 »
The live view remains active, so this will not have the battery saving of the modes that turn the sensor off.
So it should be better than just turning off the backlight but not as good as using the DISP key to turn off the display in cams with an OVF ?
Correct. But it lets you do all the things that turning off with the DISP key kills: Use Canon MF, motion detection etc.

It should be similar to the "toothpick in the A/V socket" trick, except possibly that some video out hardware might not be turned on, and it works on cameras where the A/V socket is combined with USB or doesn't work in Rec mode.

Note should also be possible to be possible to emulate the toothpick trick with levents, like

ConnectVideoCable
DisconnectVideoCable

I think I tested this at one point, but I'm not certain...

@outslider:
parens are optional in Lua if the argument is a single string or table, saves a few bytes ;)
Don't forget what the H stands for.


*

Offline dvip

  • ****
  • 451
Re: A better(?) way to control display off
« Reply #4 on: 14 / August / 2013, 17:49:50 »
I find
call_event_proc'DispCon_TurnOffDisplay'
very useful.
Works fine with my A590IS.
 
« Last Edit: 14 / August / 2013, 20:23:48 by dvip »

Re: A better(?) way to control display off
« Reply #5 on: 14 / August / 2013, 17:51:59 »
@outslider:
parens are optional in Lua if the argument is a single string or table, saves a few bytes ;)

Good to learn something everyday:) Thanks!
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick

Re: A better(?) way to control display off
« Reply #6 on: 14 / August / 2013, 20:33:38 »
D10 does not have a native display off mode. I'd like to know if it works on other cameras like this, and whether anyone sees any side effects.
Really nice work - thanks.   Works on my G10,  A1200 (both have display off modes) and my SD940 (does not have a display off mode). 

Code: [Select]
--[[
@title Display On/Off Test
--]]
set_console_layout(0, 0, 44, 10)
print("started")
if call_event_proc'DispDev_EnableEventProc' == -1 then
 if call_event_proc'DispDev.Create' == -1 then
  error'eventprocs not found'
 end
end
sleep(1000)
print("turning off the display and shooting")
sleep(2000)
call_event_proc'DispCon_TurnOffDisplay'
sleep(2000)
shoot()
sleep(3000)
call_event_proc'DispCon_TurnOnDisplay'
print("display back on")
sleep(1000)

Quote
Issues I've seen so far:
- Switching between rec and play with the display off seems to crash.
- if you turn the display off and on in play mode, the review picture is no longer visible. Switching images makes it show again.
- the bitmap ui overlay (both chdk and canon) may not display after turning on, until you do something that causes the canon firmware to refresh it.
The first issue is unfortunate .. at a minimum we will need to document it I guess.  I saw the third issue with my SD940 but not with the other two cameras

Quote
Assuming this works widely, I think we should add it as a standard script function so people don't have to enable native calls.
And by doing so, it can be a uBASIC function too ?   ;)
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 12690
Re: A better(?) way to control display off
« Reply #7 on: 14 / August / 2013, 22:35:16 »
The first issue is unfortunate .. at a minimum we will need to document it I guess.
Yes.

An alternative would be to use LcdCon_SetLcdBackLightBrightness 0. I would guess that doesn't save as much energy, and it's not clear what brightness level you'd restore to.

It may be worth tracking the set display state in script, so it could be restored if there is a script error. We could also turn it on before doing a mode switch, but I think the script would have to be responsible for turning it back off, since the actual switch isn't necessarily complete when the call returns.
Quote
And by doing so, it can be a uBASIC function too ?
Yeah, that too :P

Final question, what should the function be called in script? Following the existing pattern it should be something like set_display(0|1) but that's not particularly clear (set display what?!) I'd be tempted to use display_off and display_on.
Don't forget what the H stands for.


Re: A better(?) way to control display off
« Reply #8 on: 15 / August / 2013, 00:21:56 »
It may be worth tracking the set display state in script, so it could be restored if there is a script error. We could also turn it on before doing a mode switch, but I think the script would have to be responsible for turning it back off, since the actual switch isn't necessarily complete when the call returns.
I was thinking about that too rather than just document it.  Probably hard to get 100% right but 90% might be good enough.

I'd be tempted to use display_off and display_on.
That works for me.   But do you change set_backlight() the same way ? (or add it as a redundant command to maintain backward compatability?)
« Last Edit: 15 / August / 2013, 00:23:29 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 12690
Re: A better(?) way to control display off
« Reply #9 on: 15 / August / 2013, 00:54:30 »
It may be worth tracking the set display state in script, so it could be restored if there is a script error. We could also turn it on before doing a mode switch, but I think the script would have to be responsible for turning it back off, since the actual switch isn't necessarily complete when the call returns.
I was thinking about that too rather than just document it.  Probably hard to get 100% right but 90% might be good enough.
Should check whether calling the function when it's already in the desired state has any bad effects.

On a540, turning on when the display is already on just seems to trigger the jpeg and bitmap I mentioned earlier. I didn't notice any problems repeatedly turning it off.

I also tried SwitchOnDisplay and SwitchOffDisplay (registered with  InitializeAdjustmentFunction). These seem to behave the same as DispCon functions above. They call the same underlying functions but some code is different.

On further testing, I'm not sure the crashing on mode switch with display off was real. I was able to do it a few times (using the original DispCon_ functions, not the Switch* mentioned above) on a540 without seeing it again.

I did notice that the bitmap overlay in ptp live view doesn't seem to update reliably. It seems like the canon firmware doesn't update after a lot of actions (e.g. clicking menu doesn't change the bitmap, but after you press "down") it shows up.
Don't forget what the H stands for.

 

Related Topics