Properties

Overview

Properties are variables in DryOS to exchange information between tasks. In fact, those are some kind of broadcasted events (one task can change a value, and other parts of code can get notified when that value changes). You can setup callback functions to receive notifications for any property; they are easy to use, thanks to Trammell's PROP_HANDLER macros.

The properties usually take integer or string values. Each property has a "len" parameter, which specifies the amount of bytes used for the value (e.g. for an integer property, len=4).

Properties are used for lots of stuff (e.g. ISO, shutter speed, aperture, focus, white balance, remaining shots / recording time etc). Many (but not all) properties are similar between 5D2 and 550D.

There are also other kind of events, unrelated to properties, for example, GUI events. See GUI Events, GUI Events/550D and CHDK. There are also persistent parameters (remembered when camera is turned off); for those, see the Params page at CHDK wiki.

Reading / writing properties

• To be notified via a callback when another task modifies a property, use the PROP_HANDLER macro:

PROP_HANDLER(PROP_SHOOTING_TYPE)
{
	int shooting_type = buf[0];   // uint32_t* buf contains the property value
                                     // you also have a variable "unsigned len", which contains the length of the data.
       // do something with it
	return prop_cleanup( token, property );  // always return this
}

Low level stuff: you can also use prop_register_slave() to be notified via a callback.

• To modify a property, use prop_request_change(property, addr, len).

See Magic_Lantern_API and lens.c for usage of the property-related functions. See property.h for a list of properties used in Magic Lantern code, and add new ones in this file.

Discovering properties

thumb|300px|right|Draw-prop example: discovering flash-related properties

We can see all PROP_* related outputs with:

• the draw_prop option in the Debug menu.
• the dumpf command: dumpf; Debugging Magic Lantern

Properties can also be found by static analysis of the code:

• tracing the calls to prop_request_change
• decompiling the ARM code backwards, from debug strings
• a rough automatic analysis of properties can be done with GPL Tools/ARM console.

Other useful links:

• See also on CHDK wiki Property_list (May 2009)
• See Lens info properties events in DryOS
• See also CAMSET00.DAT file.

Properties functions

prop_register_slave()

here is what I believe to be the way to register a function to be called if a list of properties is changed.

- first the list (of 9 properties, each of 4 bytes) is copied into other piece of memory.

- then prop_register_slave() is called with r0 = properties_list, r1=num_properties, r2=function_called, r3=0, [SP]=function_that_does_update

- thus it seems prop_register_slave(void* properties_list, int num_properties, void* function_called, int arg_maybe, void *update_func )

ROM:FF19D6E8                 LDR     R1, =properties_list_9items ; src
ROM:FF19D6EC                 ADD     R0, SP, #0x30+dest ; dest
ROM:FF19D6F0                 MOV     R2, #0x24 ; '$' ; size
ROM:FF19D6F4                 BL      memcpy
ROM:FF19D6F8                 ADR     R3, mac_update_and_give_sem
ROM:FF19D6FC                 STR     R3, [SP]
ROM:FF19D700                 MOV     R3, #0
ROM:FF19D704                 ADR     R2, mac_prop_handler
ROM:FF19D708                 MOV     R1, #9
ROM:FF19D70C                 ADD     R0, SP, #0x30+dest
ROM:FF19D710                 BL      prop_register_slave
...
ROM:FF0574A0 prop_register_slave() 
...
ROM:FF4C3DEC properties_list_9items DCD 0x1000006    ; DATA XREF: mac_register_properties+8
ROM:FF4C3DEC                                         ; ROM:off_FF19D938
ROM:FF4C3DF0                 DCD 0x1060001
ROM:FF4C3DF4                 DCD 0x1060002
ROM:FF4C3DF8                 DCD 0x1060003
ROM:FF4C3DFC                 DCD 0x1060005
ROM:FF4C3E00                 DCD 0x1060004
ROM:FF4C3E04                 DCD 0x1060000
ROM:FF4C3E08                 DCD 0x100000B
ROM:FF4C3E0C                 DCD 0x1000008

prop_request_change()

See here [1] and in property.h.

this is the function to update a property value.

R0 is the property "name", r1 is supposed to be where the property value is stored (a pointer), and R2 is the sizeof the new value (in bytes).

ROM:FF2028E8                 ADR     R2, aProp_requestProp_compression_lD ; "PROP_Request PROP_COMPRESSION_L (%d)"
ROM:FF2028EC                 BL      DebugMsg
ROM:FF2028F0                 LDR     R1, =unk_14D44
ROM:FF2028F4                 LDR     R0, =0x2020001
ROM:FF2028F8                 MOV     R2, #4
ROM:FF2028FC                 BL      prop_request_change

ROM:FF20292C                 ADR     R2, aProp_requestProp_compression_m1D ; "PROP_Request PROP_COMPRESSION_M1 (%d)"
ROM:FF202930                 BL      DebugMsg
ROM:FF202934                 LDR     R1, =unk_14D48
ROM:FF202938                 LDR     R0, =0x2020002
ROM:FF20293C                 MOV     R2, #4
ROM:FF202940                 BL      prop_request_change

See http://magiclantern.wikia.com/wiki/Properties/prop_request_change

Internals

You can see what code calls the property slaves by examining the call stack.

property slave
0xff1b6514 prop_delivery_maybe
0xff1b712c AJ_AnalyzeMpuReceiveData
0xff1d852c AJ_StateObj (state probably around ff544b59)
0xff1d84f4 AJ_StateObject_stuff => FUNC(arg0->off_0xC)(arg0, arg1, arg2, arg3)
0xff056c84 EventDispatch
0xff1d8a3c AJ_UserLevel_task
0xff0771c0 FUNC((*(arg0))->off_0xC)((*(arg0))->off_0x10, (*(arg0))->off_0xC, arg2, arg3) // somewhere near task trampoline functions

Functions called from prop_delivery_maybe:

0xff1b6358 get_property_list_of_slaves_maybe
  => calls 0xff1b62f8 get_property_group_maybe
0xff0575c0 prop_cleanup [why called from here?!]