I don't know how to determine if the active_bitmap_buffer is valid except by searching the disassembly which suggested the current value to me. What should I check?
Does index the current bitmap buffer? It should switch between 0 and 1 when the canon firmware updates, and indexing the bitmap and opacity buffers with it should give you the current display.
It seems to me, looking at the sx50 lib.c, it should be possible to replace a lot of code in my lib.c, however, both the g7x and sx280 seem to have adopted a different approach which I am using for now.
sx50 is a digic 5 camera, so most of the bitmap and framebuffer related stuff is actually different.
Is there something else that would be better to focus on before this?
I'd suggest getting the kbd.c / kbd_task as complete as you can. It looks like the KEYS_MASKn entries don't match what's in the keymap.
The mask should be the bitwise OR of all the keys that are in a particular word of physw status, except KEY_POWER, which shouldn't be masked.
You should make sure the keys are defined correctly, for example by watching physw_status while pressing the keys.
Note, to unlock the keyboard in playback with USB connected, you can use
=post_levent_to_ui(4484)
I would also suggest verifying the propset. As a guess, I'd expect sx60 to use the same propset as g7x, since it's the same dryos version, but it might not be the case. Verifying the propset mostly involves changing settings in the canon UI and making sure the corresponding propcase has the expected value. For example, if you switch to M mode and set the shutter speed, you should see the APEX96 value in USER_TV, and after you have half pressed, you should see it in TV and TV2 as well.
If you check a few with a range of IDs and they are all OK, it's probably safe to assume it's right.
You get get individual propcase values in chdkptp using
=return get_prop(id)
Or by name with something like
=p=require'propcase' return get_prop(p.TV)
I also use this chdkptp script:
https://chdk.setepontos.com/index.php?topic=12759.0 I see you still have some FAKEDEF(..., 0) in stubs_min.S. As I mentioned earlier, this is a mistake:
https://chdk.setepontos.com/index.php?topic=12532.msg127202#msg127202Best strategy to debug?
My preferred strategy for debugging capt_seq is to use PTP, uart redirection, LogCameraEvent, and show camera log. You can see some examples of log calls in the g7x capt_seq.c
Note you have to be careful about where you put log in the assembly, it's up to you to make sure you don't trash registers or condition codes.
Once you have the log calls set up, use the following to start UART logging with reasonable sized buffers:
=call_event_proc('StopCameraLog') sleep(200) call_event_proc('StartCameraLog',0x20,0x6000) sleep(100) require'uartr'.start('A/test.log',true,0x8000)
then switch to rec and shoot or whatever you want to test, and call
=return call_event_proc('ShowCameraLog')
Then download test.log to see your log messages in sequence with the normal camera log output.
E.g.
00111020: UI:VTMUnLock
00111220: UI:cs override arb:0 rb:0x435ee300 i:0105
00111220: UI:ShootSeqToUI:0x00002006:adr:0x8340,Para:33600
00111220: UI:cs end m:0 arb:0 rb:0x435ee300 i:0105
00111220: UI:cs m:34 arb:0 rb:0x435ee300 i:0105
00111220: UI:ShtCon_SetPreCapt
00111220: UI:VTMLock
The UI:cs messages are mine, the others are normal camera logging.
capt_seq task (like many canon tasks) sits in a loop reading messages and doing things in response to them. Message 0 is sent when the camera is ready after half shoot (or before starting the shot if the user didn't wait). Message 1 is sent for an actual shot. Most of the others are responses to shooting related setting changes, but we don't do much with them.
The code path within the message 1 code can vary a lot depending on the shooting mode, whether the user waited for half press etc.
The exposure override hook needs to be somewhere in message 0 code (probably very similar to sx280hs and g7x)
The remote hook should be somewhere shortly before the actual exposure starts
The raw hook should somewhere after the exposure has completed, but before the canon firmware has kicked off the jpeg process.
If the raw hook isn't implemented, CHDK scripted shoot() and various other features will not work correctly, even if you aren't using CHDK raw.
