Mode dials and Playback pushbuttons

  • 201 Replies
  • 26810 Views
*

Offline reyalp

  • ******
  • 10067
Re: Mode dials and Playback pushbuttons
« Reply #60 on: 25 / October / 2009, 16:54:15 »
Advertisements
Not really (well I didn't check today but I think I wrote that wikia table)...get_prop result in scripts doesn't equal to modemap[] or debug propcase viewer in CHDK C code due to different assumptions of datatypes and whatnot.
This is a bug. The get_mode() code reads the the mode value as a 32 bit int. This is the actual correct value. The property case code reads values as a 16 bit signed int. This means that some mode values appear negative, which would be OK if they stayed in a 16 bit int, but they get passed into a 32 bit int, where they get sign extended to a negative 32 bit value. You can get the original, correct value in script by doing a bitwise and with 0xFFFF.

I'd like to fix this, but it would break scripts >:(
Don't forget what the H stands for.

*

Offline fe50

  • ******
  • 3038
  • IXUS50 & 860, SX10 Star WARs-Star RAWs
    • fe50
Re: Mode dials and Playback pushbuttons
« Reply #61 on: 25 / October / 2009, 17:33:01 »
Quote
2) MODE menu: most things are working; after setting a mode by script you can't select another mode with the Canon UI...
Quote
If you use "Reset Masked EV" (which I forgot to mention in the documentation!) this the mode dial should work again.
Found this already while testing, it works on the SD870 ... but not with the SX10:
After the reset, each (physical) dial mode change results in a "undefined" behaviour: the Canon video OSD symbol is shown, no manual controls...also switching to playback mode & back to rec mode doesn't do the trick...

I'll do some more tests...

*

Offline reyalp

  • ******
  • 10067
Re: Mode dials and Playback pushbuttons
« Reply #62 on: 25 / October / 2009, 17:38:44 »
Interesting.

Does it make a difference if you switched the camera to record mode using the normal buttons vs. the script ?

Does the behavior of not being able to use the physical mode dial continues after your quit the script ?

edit:
UIFS_SetCaptureModeToP UIFS_SetDialMovieRec and UIFS_PostModeDial all call sub_FF948F8C, which calls SetLogicalEventActive on all the ModeDialTo from 0x1052 ModeDialToM up to 0x1064 ModeDialToFunColor (so it excludes Rec and Sports, like a540) It also calls it on one more:
0x1078, 4216,RotateExpDialLeft,2

It does not call SetLogicalEventActive on the later mode dial events, starting at 0x1073, ModeDialToNightSnap.

I'd try setting N in the mask menu on:
0x1073, 4211,ModeDialToNightSnap,2
0x1074, 4212,ModeDialToParty,2
0x1075, 4213,ModeDialToKidsAndPets,2
0x1076, 4214,ModeDialToEasy,2
0x1086, 4230,ModeDialToQuick,2
0x1087, 4231,ModeDialToCreative,2

« Last Edit: 25 / October / 2009, 17:53:30 by reyalp »
Don't forget what the H stands for.

*

Offline fe50

  • ******
  • 3038
  • IXUS50 & 860, SX10 Star WARs-Star RAWs
    • fe50
Re: Mode dials and Playback pushbuttons
« Reply #63 on: 25 / October / 2009, 18:04:39 »
Does it make a difference if you switched the camera to record mode using the normal buttons vs. the script ?
No.
Quote
Does the behavior of not being able to use the physical mode dial continues after your quit the script ?
No; the dial mode works normal after i quit script with the shutter...

One thing i've noticed:
When the mode dial is changed to the mode i've set before with the script, the OSD changes in normal speed(~0.5 - 1s);
changing to all other positions shows the OSD much slower, it stocks several times and needs ~ 2 seconds.

The effect happens when the mode dial is changed in <Alt> mode while the script is running and also when the script is paused (<Alt> mode off).

*EDIT - for the file & as a hint for all the others  :)
Changing "Script mode" to 0 does the trick !

« Last Edit: 25 / October / 2009, 18:43:24 by fe50 »


*

Offline fe50

  • ******
  • 3038
  • IXUS50 & 860, SX10 Star WARs-Star RAWs
    • fe50
Re: Mode dials and Playback pushbuttons
« Reply #64 on: 25 / October / 2009, 18:25:06 »
Quote
3) PRESS/UNPRESS: most things are working; on the Ixus cams some events must be used twice, e.g. PressFlashButton on the SD870...
Interesting. Maybe try a script that does a press/unpress pair ?

Tested again, it works with a single press / unpress combination.
Unpress is needed, after unpress there's the Canon delay (~ 3 seconds) before the OSD disappears  ;)

*

Offline reyalp

  • ******
  • 10067
Re: Mode dials and Playback pushbuttons
« Reply #65 on: 25 / October / 2009, 20:41:31 »
I've started a wiki page for events http://chdk.wikia.com/wiki/LogicalEvent

I'll try to flesh it out as time goes on, but please feel free to collect observations there.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 10067
Re: Mode dials and Playback pushbuttons
« Reply #66 on: 26 / October / 2009, 19:48:56 »
Another thing I noticed. UI_RegistDebugEventProc calls a function (sub_FFD51120 on a540) which  appears to register every event (or maybe every named event ?) as an eventproc.

I've tested ExecuteEventProc("PressPowerButton") and it works :D
Don't forget what the H stands for.

Re: Mode dials and Playback pushbuttons
« Reply #67 on: 26 / October / 2009, 20:09:35 »
On the A620, dumplev.lua created dmplev.csv with 515 events.
testlev2.lua switched from playback to record, entered manual mode and took photo.
Switched to movie mode and recorded ten second clip.
Played the movie.
Started from record mode, all the above events were repeated.

testlev.lua forced record or play.
All supported dial modes worked including play but record crashed camera.

Will try and do more tomorrow.


*

Offline reyalp

  • ******
  • 10067
Re: Mode dials and Playback pushbuttons
« Reply #68 on: 27 / October / 2009, 03:00:25 »
All supported dial modes worked including play but record crashed camera.
Just to be clear, you mean selecting ModeDialToRec crashed ? If so, you could try switching the Mask option on this item.

However, it seems like PressRecButton and PressPBButton (probably paired with Unpress) work on every camera so far, so no need to worry about it too much.



For anyone who wants input on the process, here's my thoughts how this is going to go into CHDK
- Use the PressRec/PressPB method to force Record/Playback.
For some cameras (probably all those switch rather than rec/play buttons) we need to find a variable or function to get the actual state, because they rely on physw_status bits related to the switch to detect mode. This should still be easier than figuring out and overriding the switch bits.
The script interface for this can be as simple as
force_play_mode and force_record_mode

- Probably use SetCurrentCaptureModeType for modes, either by finding the function on every camera, or as an eventproc.
This need more testing. I can provide builds for any camera, just ask. This is available in the eventproc patch http://chdk.setepontos.com/index.php/topic,4417.msg42326.html#msg42326
If this works on all cameras, it is much better than dial overrides. You can set any of the available modes, whether they are accessed by dial, switch, func menu etc. We already have a modemap for each camera, so they can be referred to by standard constants that already exist.
the script interface to this would be
set_capture_mode(x), where x is either a CHDK modemap constant, or (in lua) a string. I would also put in a function to determine if a particular mode is valid on the camera, and one to translate between canon propcase mode values and CHDK values.

With the above, I don't think we need a specific movie override.

In lua, almost all of this could be written in lua with just the eventproc interface, but if we are going to write functions for ubasic, we might as well provide the same simple built in interface to lua.

For all of the scripted overrides, it would be nice to be able to restore things to the original state when the script ended. OTOH, some people might want scripts that set things are particular way and then exited ?
Don't forget what the H stands for.

*

Offline whoever

  • ****
  • 280
  • IXUS950
Re: Mode dials and Playback pushbuttons
« Reply #69 on: 27 / October / 2009, 13:21:39 »
Came at last to compiling and checking this out on Ixus950 (wow, is this what it looks today? Can barely recognize the menus...), and yes, testlev2.lua works as advertised. Except I changed "ModeDialToM" to "ModeDialToP", as there's no true M-mode here, and added some sleep between "PressSwTwo" and "UnpressSwTwo", as otherwise it didn't want to take a shot.

Amazing.

When it comes to finding out the current mode, which is not necessarily determined by the dial position anymore, the record modes are still correctly reflected in propcases 49/50 (and also in a variable that happens to be at 0x23A8 here), but these do not change on entering the play mode... I probably have to add that there's no play button on this cam. (And yes, mode_get() indeed relies on physw_status.)

Surely, there's another variable that does change in play mode. Here it is at 0x23AC, and its value is always 0xFFFF in play and something else otherwise. Not sure how to find it in general -- it is referenced in quite a few places that are not easily recognizable. Except perhaps for one particular piece of code that explicitly compares the value with 0xFFFF,
Code: [Select]
FF82AED8             sub_FF82AED8                            ; CODE XREF: sub_FF8242D8+4 p
FF82AED8 14 30 9F E5                 LDR     R3, =0x23AC     ; Load from Memory
FF82AEDC FF 0C A0 E3                 MOV     R0, #0xFF00     ; Rd = Op2
FF82AEE0 B0 20 D3 E1                 LDRH    R2, [R3]        ; Load from Memory
FF82AEE4 FF 00 80 E2                 ADD     R0, R0, #0xFF   ; Rd = Op1 + Op2
FF82AEE8 00 00 52 E0                 SUBS    R0, R2, R0      ; Rd = Op1 - Op2
FF82AEEC 01 00 A0 13                 MOVNE   R0, #1          ; Rd = Op2
FF82AEF0 0E F0 A0 E1                 RET                     ; Return from Subroutine
FF82AEF0             ; End of function sub_FF82AED8
but it looks too short for autodetection. The nearest identifiable strings are "ShutdownRecMode" and "ExitRecModeBeforeStopEVF ". And I probably have to add that it is an ancient VxWorks camera.

edit: I do find something similar in DryOS A720_100c @FFC62334 and sd1000_102a @FF829378. Don't have later disasms to check.
« Last Edit: 27 / October / 2009, 13:31:32 by whoever »

 

Related Topics