supplierdeeply

UI properties (PTM functions)

  • 47 Replies
  • 3284 Views
*

Offline srsa_4c

  • ******
  • 3118
  • Publish
    UI properties (PTM functions)
    « on: 01 / September / 2013, 13:16:09 »
    Advertisements
    While I was trying to find a solution to SticK's ISO problem, I started to notice magic constants in the 0x80xx range. They always seemed to appear in UI related functions. I started tracing them, and found out that there are event procedures which work with these 0x80xx IDs.
    I was a bit surprised to see that these event procedures were never discussed before.

    PTM stands for "Property Table Manager" as indicated by debug strings. Two of these functions are already in use by CHDK:
    PTM_BackupUIProperty: SetParameterData (CHDK name)
    PTM_RestoreUIProperty: conditionally calls GetParameterData (CHDK name)
    The above two functions work with IDs in the 0x40xx range, and manage the "flash params" - settings which are stored in flash.

    A different subset of the PTM functions works with 0x80xx IDs. They are camera dependent, and I don't know what most of them do.
    In cases I have seen, the IDs are connected to certain UI elements (Canon calls these "controllers").

    For example, on the a3200 (DryOS r47):
    0x8021: focus mode (0 = normal, 1 = macro, 3 = "infinity")
    0x800a: ISO setting (0 = auto, 1 = 80, 2 = 100, 5 = 200, ..., 14 = 1600)

    On the a410 (yes, many of these event procedures are available even on the first DIGIC II models):
    0x8005: ISO setting (0 = auto, 1 = 50, 2 = 100, 3 = 200)

    sx100 (DryOS r23):
    0x8005: ISO setting (0 = auto, 1 = hi ISO, 2 = 80, 3 = 100, 4 = 200, ..., 7 = 1600)

    The current value of these UI properties can always be read (PTM_GetCurrentItem). Setting them is also possible (PTM_SetCurrentItem), but one must take care when doing so.
    - values not supported in the current mode are either rejected (bit0 of the return value is set), or can even cause assert
    - reading and writing unsupported IDs results in an assert
    - although they seem to be well protected, it's unknown whether it's possible to enter invalid values which end up in a flash setting
    - all UI properties are short integers (16bit)
    - writing to these properties has an immediate effect on the UI and the underlying setting

    Usually almost every setting found in the Canon shooting menu can be connected to some ID. Other settings (which are not in the shooting menu, but are available on keypress) are also have an ID - usually. A certain user interface element (like the ISO control) is always tied to the same ID.

    Not all settings are part of the UI properties. The a3200 has a long shutter mode, in which one can specify the exposure time. This setting appears in a UI element that is found in the regular Canon menu, and I haven't been able to find it among the UI properties. The regular Canon menu (the one you enter with the Menu button) is not connected to this property system.
    The UI flash setting appears to influence at least 3 UI properties.

    The most important event procedures:
    PTM_GetCurrentItem(<ID>): returns the current value of the specified UI property
    PTM_SetCurrentItem(<ID>, <value>): sets the specified UI property, returns 0 when the setting is accepted
    I haven't tried the following functions, but their name is descriptive:
    PTM_PrevItem
    PTM_NextItem
    There are even more related event procedures, but I haven't done much research on them.

    The PTM functions are registered with

    UI_RegistDebugEventProc on old VxWorks cameras
    UI.CreatePublic on newer models

    Some details on usage can be found here: http://chdk.setepontos.com/index.php?topic=8801.msg104253#msg104253 and the followup posts.


    tl;dr:

    Keypress-based manipulation of the UI can be replaced
    by this method in some cases.


    Attached patch adds another "debug data display" page to CHDK, called UIProp. It can be used to discover the IDs of UI elements. The patch is not suitable for inclusion into the official source in this - incomplete - form.

    To use the patch:
    - you need PRIMARY.BIN for your camera to allow the sigfinder to find the functions
    - put get_uiprop_count() found in stubs_entry.S into platform/<camera>/lib.c
    - on VxWorks, you need to locate PTM_GetCurrentItem, and the number of UI properties inside the PTM_SetCurrentItem firmware function (it's possible to locate them automatically of course)


    Observations and corrections are welcome.

    *

    Offline reyalp

    • ******
    • 9881
  • Publish
    Re: UI properties (PTM functions)
    « Reply #1 on: 01 / September / 2013, 14:02:32 »
    Excellent work :)

    FWIW, the "long shutter" option uses the same USER_TV propcase as M and TV modes. I don't know if this is relevant.

    If someone does manage to corrupt the flash params, some posts in this thread may be useful: http://chdk.setepontos.com/index.php?topic=5660.msg55221#msg55221
    Don't forget what the H stands for.

    *

    Offline nafraf

    • *****
    • 1256
  • Publish
    Re: UI properties (PTM functions)
    « Reply #2 on: 01 / September / 2013, 14:31:33 »
    Using chdkptp, diff and bash scripts. I mapped some properties for A810 and SX160. File in attachment.

    I have not seen any option to control flash power in A810 using Canon interface, but it is possible using PTM commands.
    « Last Edit: 01 / September / 2013, 14:52:36 by nafraf »

    *

    Offline srsa_4c

    • ******
    • 3118
  • Publish
    Re: UI properties (PTM functions)
    « Reply #3 on: 01 / September / 2013, 17:52:21 »
    Using chdkptp, diff and bash scripts. I mapped some properties for A810 and SX160. File in attachment.

    I have not seen any option to control flash power in A810 using Canon interface, but it is possible using PTM commands.
    Really interesting. Your findings mean that
    - some settings found in the regular menu can have UI prop IDs (mute, is that the main mute switch in the Canon menu?)
    - some invisible controls can be effective (flash power, I suppose that's the flash exposure compensation?)

    There are separate PTM functions for mode change related purposes, but I usually ended up with a confused shooting menu after using PTM_SetCurrentCaptureMode.

    I can confirm that the manual flash exposure compensation(?) does work on the a3200 in P mode (no such setting on this cam either). The ID for me is 0x8013.
    edit: this setting does not get saved, camera starts with the default value next time.
    « Last Edit: 01 / September / 2013, 17:59:40 by srsa_4c »


    *

    Offline nafraf

    • *****
    • 1256
  • Publish
    Re: UI properties (PTM functions)
    « Reply #4 on: 01 / September / 2013, 18:49:36 »
    - some settings found in the regular menu can have UI prop IDs (mute, is that the main mute switch in the Canon menu?)
    Yes, it is the main mute switch in the Canon menu.

    Some UI properties found in A495 (DryOS r43). Mute works here too.


    *

    Offline srsa_4c

    • ******
    • 3118
  • Publish
    Re: UI properties (PTM functions)
    « Reply #5 on: 17 / August / 2014, 19:03:43 »
    Updated patch attached. Complete sigfinder support (Vx, DryOS), the new feature is available on all ports.
    I have added a new macro named "FW_CONST" to stubs_asm.h, which enables the sigfinder to output a ready-to-use constant (so no per-camera edits are needed). The particular constant in this case is the number of UI properties, which only appears as immediate constant in the firmware (impossible to use the DEF macro).
    The current goal of the patch is to add the new debug display as mentioned in the opening post.
    Further possibilities include (after camera-specific research):
    - switching between drive modes (single, continuous, etc)
    - correctly enabling/disabling native RAW ( ;))

    This method won't enable getting/setting native Tv, Av, subject distance, (...) values, unfortunately.

    I'm thinking about committing this unless somebody convinces me not to :)
    I'm also open to suggestions.

  • Publish
    Re: UI properties (PTM functions)
    « Reply #6 on: 17 / August / 2014, 19:19:22 »
    I'm thinking about committing this unless somebody convinces me not to.
    Would it make more sense to add this to 1.4.0 when 1.3.0 finally rolls over to being called stable ?  It's so close to stable now we might want to consider a "code freeze" ?
    « Last Edit: 17 / August / 2014, 19:22:23 by waterwingz »

    *

    Offline srsa_4c

    • ******
    • 3118
  • Publish
    Re: UI properties (PTM functions)
    « Reply #7 on: 17 / August / 2014, 19:32:11 »
    I'm thinking about committing this unless somebody convinces me not to.
    Would it make more sense to add this to 1.4.0 when 1.3.0 finally rolls over to being called stable ?  It's so close to stable now we might want to consider a "code freeze" ?
    There's a huge pile of changes/features scheduled for 1.3 (see http://chdk.setepontos.com/index.php?topic=10459.msg113546#msg113546 and the followup posts), this one is really simple compared to those. But I noted your objection.


  • Publish
    Re: UI properties (PTM functions)
    « Reply #8 on: 17 / August / 2014, 19:34:51 »
    But I noted your objection.
    It was more of a suggestion than an objection.   And maybe a little nudge towards reyalp (who I know has been working on that list).

    *

    Offline koshy

    • *****
    • 686
  • Publish
    Re: UI properties (PTM functions)
    « Reply #9 on: 17 / August / 2014, 19:46:34 »
    Would it make more sense to add this to 1.4.0 when 1.3.0 finally rolls over to being called stable?  It's so close to stable now we might want to consider a "code freeze" ?
    I read this thread and know to little about the internal workings of things to judge the suggestion of WWZ but I figured a suggestion / question might still be helpful.
    The current goal of the patch is to add the new debug display as mentioned in the opening post.
    Further possibilities include (after camera-specific research)
    I suppose the main purpose is the aquisition of information that isn't yet available by using the new debug display on various cameras. Well, the question is do you know what information you'd like? Can you give a sound step by step of what to collect / can the information be collected by a script. If I know what I'm getting into by suggesting this I might suggest to just execute the data gathering on the 80 camera models I currently own. That I could do by compiling a patched trunk for all cameras in question so you might get the data you're interested in even though this isn't commited yet. If you do commit it I might still do what I outlined but like I said I'd like to know what I'm getting myself into first :D

    Edit: I have no camera capable of a native RAW at this point so I'll be no help on that...
    « Last Edit: 17 / August / 2014, 19:48:48 by koshy »

     

    Related Topics