As I mentioned in
@Recyclojunk64's
thread, this is an area I've been poking around recently for the PTP / WIFI unlock stuff, so here's a thread to document. I suspect
@srsa_4c has already found a lot of this. What follows is my current guesses, errors are likely
In the firmware, a "controller" is a small data structure allocated from
UI memory, which primarily consists of a function that receives
events sent with PostLogicalEventToUI etc. (and other ways, see below)
The controller structure varies across cameras (from 4 words on a540, to 10 on g7x), but the first 3 fields appear to consistently be
1) function pointer passed to CreateController
2) 2nd argument passed to CreateController. Often 0, otherwise presumably controller specific data.
3) Pointer to next controller in the "z order"
Controllers are organized in a "z order" where the topmost controller receives events first. A pointer to the topmost controller is referenced in CreateController (elph130 0x3cb0), and the remaining controllers are in a linked list defined in the controller structures
The controller function appears to receive 4 arguments.
1) Controller specific data from CreateController 2nd argument
2) Event ID
Not sure of the rest, but one is likely the parameter that can be included with PostLocicalEvent functions
The return value determines whether events are received by controllers lower in the z order, 0 = no, 1 = yes (from
the shooting with canon basic thread)
As far as I can tell, controllers functions normally run in task_CtrlSrv, but may be called from other tasks for some messages, like the on create and delete ones mentioned below.
Hooking controllers:
You could traverse the list manually and set the function pointer, or on dryos r43 and later, use ui_malloc to hook controller creation (
https://chdk.setepontos.com/index.php?topic=14196.msg145689#msg145689)
It would also be possible to call controller functions directly, to "send" messages outside the normal message system
Controller eventprocs:
controller_struct *CreateController_FW(void *controller_fn, void *param);
void DeleteController_FW(controller_struct *controller);
GetSelfControllerHandle_FW
CtrlMan_ChangeZOrder_FW
MoveControllerToTopOfZOrder_FW
CreateController_FW calls some potentially interesting functions. On elph130, the last two calls after a successful creation are
ff0c3c1c(new_controller,0x803,0);
ff0c41e8(previous_top_controller,new_controller);
The first function (ff0c3c1c) appears to be a dispatch function which sends an event to an individual controller (as opposed to traversing the whole list). Presumably, 0x803 tells the newly created controller that it's been created.
The second function (ff0c41e8) calls the first, sending 0x802 to the old top controller, and 0x801 to the new one. It's also used by DeleteController.
From experimenting on elph130:
When PTP is connected and the keyboard is "locked", the top controller function is ff230588. The corresponding CreateController call is in ff2306ec, which references the string "AllConsumeController.c") - presumably, a controller that eats all keyboard events.
Using post_levent_to_ui(4484) causes this controller to be removed from from the controller list. This leaves function ff209a6c on the top, which is created in ff209d0c, which is called from CreateDialogBox
