Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - a1ex

Pages: [1] 2 3 ... 382
Draft patch:
Code: [Select]
diff -r 1324f51b5e85 src/boot-hack.c
--- a/src/boot-hack.c
+++ b/src/boot-hack.c
@@ -462,2 +462,31 @@
+    /* should we require SET for loading ML, or not? */
+    extern int _set_at_startup;
+    _set_at_startup = config_flag_file_setting_load("ML/SETTINGS/REQUIRE.SET");
+    // at this point, gui_main_task should be started and should be able to tell whether SET was pressed at startup
+    if (magic_off_request != _set_at_startup)
+    {
+        /* should we bypass loading ML? */
+        /* (pressing SET after this point will be ignored) */
+        magic_off = 1;
+        /* fixme: enable on all models */
+        extern char additional_version[];
+        additional_version[0] = '-';
+        additional_version[1] = 'm';
+        additional_version[2] = 'l';
+        additional_version[3] = '-';
+        additional_version[4] = 'o';
+        additional_version[5] = 'f';
+        additional_version[6] = 'f';
+        additional_version[7] = '\0';
+    #endif
+        /* do not continue loading ML */
+        return;
+    }
@@ -878,33 +907,8 @@
     // wait for overriden gui_main_task (but use a timeout so it doesn't break if you disable that for debugging)
-    for (int i = 0; i < 30; i++)
+    for (int i = 0; i < 50; i++)
         if (ml_gui_initialized) break;
-        msleep(100);
+        msleep(50);
-    msleep(200);
-    // at this point, gui_main_start should be started and should be able to tell whether SET was pressed at startup
-    if (magic_off_request)
-    {
-        magic_off = 1;  // magic off request might be sent later (until ml is fully started), but will be ignored
-        for (int i = 0; i < 10; i++)
-        {
-            if (DISPLAY_IS_ON) break;
-            msleep(100);
-        }
-        bmp_printf(FONT_CANON, 0, 0, "Magic OFF");
-        info_led_off();
-        extern char additional_version[];
-        additional_version[0] = '-';
-        additional_version[1] = 'm';
-        additional_version[2] = 'l';
-        additional_version[3] = '-';
-        additional_version[4] = 'o';
-        additional_version[5] = 'f';
-        additional_version[6] = 'f';
-        additional_version[7] = '\0';
-    #endif
-        return ans;
-    }
+    msleep(50);
diff -r 1324f51b5e85 src/config.c
--- a/src/config.c
+++ b/src/config.c
@@ -282,3 +282,3 @@
-int config_flag_file_setting_load(char* file)
+int config_flag_file_setting_load(const char * file)
@@ -288,3 +288,3 @@
-void config_flag_file_setting_save(char* file, int setting)
+void config_flag_file_setting_save(const char * file, int setting)
@@ -304,3 +304,2 @@
     config_flag_file_setting_save(autosave_flag_file, !!config_autosave);
-    msleep(50);
     config_autosave = !config_flag_file_setting_load(autosave_flag_file);
@@ -858,5 +857,16 @@
+/* initialized and used in boot-hack.c */
+int _set_at_startup = 0;
+static MENU_SELECT_FUNC(set_at_startup_toggle)
+    /* this one is a bit hard to integrate with config presets, so it's made global */
+    const char * flag_file = "ML/SETTINGS/REQUIRE.SET";
+    config_flag_file_setting_save(flag_file, !_set_at_startup);
+    _set_at_startup = config_flag_file_setting_load(flag_file);
 static struct menu_entry cfg_menus[] = {
-    .name = "Config files",
+    .name = "Config options",
     .select = menu_open_submenu,
@@ -867,2 +877,13 @@
+            .name       = "SET at startup",
+            .priv       = &_set_at_startup,
+            .max        = 1,
+            .choices    = CHOICES("Bypass loading ML", "Required to load ML"),
+            .select     = set_at_startup_toggle,
+            .icon_type  = IT_BOOL,
+            .help       = "[GLOBAL] If you hold the SET button pressed at camera startup:",
+            .help2      = "Do not load ML if you start the camera with SET pressed (default)\n"
+                          "Load ML only if SET is pressed at startup (optional)"
+        },
+        {
             .name = "Config preset",
diff -r 1324f51b5e85 src/config.h
--- a/src/config.h
+++ b/src/config.h
@@ -149,4 +149,4 @@
 /* simple boolean settings that live outside of config files (just by presence of a file) */
-int config_flag_file_setting_load(char* file);
-void config_flag_file_setting_save(char* file, int setting);
+int config_flag_file_setting_load(const char * file);
+void config_flag_file_setting_save(const char * file, int setting);
diff -r 1324f51b5e85 src/menuindex.c
--- a/src/menuindex.c
+++ b/src/menuindex.c
@@ -27,2 +27,5 @@
+/* config.c */
+extern int _set_at_startup;
 static struct menu_entry help_menus[] = {
@@ -117,2 +120,11 @@
+        .select = menu_nav_help_open,
+        .name = "SET at startup",
+        .priv = &_set_at_startup,
+        .max  = 1,
+        .icon_type = IT_ACTION,
+        .choices = CHOICES("Bypass loading ML", "Required to load ML"),
+        .help = "To change this setting: Prefs -> Config options",
+    },
+    {
         .name = "Key Shortcuts",

Format card and keep Magic Lantern even though it was disabled? Good point, will think about it (would require a background task to monitor Canon menu).

[edit: it's not trivial, a lot of checks there require properties - hooks in Canon code; if we go that far, you may as well create a config preset with most of the stuff turned off]

Yeah, a better message could work, but didn't want to go to the trouble of loading the fonts just for that.

Alright, suggestion for menu entry welcome (out of inspiration). Found a place to implement it without disturbing the overall startup process.

I'd also disable the "Magic OFF" message (which is no longer working for quite some time) and replace it with something simpler (LED fade out?)

General Development Discussion / Re: ML UI rationalization
« on: Yesterday at 02:56:20 PM »
Some UI updates committed to lua_fix (will be in the next build; feel free to compile from source for early testing):

- EOS M has SET/Q, just like 100D; now this button is handled in the same way on both models:
    -> short press = SET (including ETTR trigger, exposure presets and whatever else uses the SET key in ML)
    -> long press = Q (Canon settings)
- 100D, EOSM: hold SET at startup to bypass ML (just like all other models; previously, these two used INFO)
- all models: disabled the Junkie menu (can be re-enabled with FEATURE_JUNKIE_MENU in features.h); MENU just goes back
- all models: PLAY opens submenus (in addition to Q)

All of the above were tested in QEMU.

Let me know how it feels (I can revert any of them if needed).

Alright, committed to lua_fix branch.

Code: [Select]
5DFEE>    PropMgr:0049363c:00:00: *** mpu_send(06 05 02 0a 01 00), from 42dc                         ; PROP_PERMIT_ICU_EVENT
5E454> **INT-36h*:004936a4:00:00: *** mpu_recv(06 05 06 20 01 00), from 36438                        ; BGMT_Q
5E656>   MainCtrl:ff0cc664:89:03: bindReceiveSwitch (32, 1)
5E687>   MainCtrl:ff0d6368:85:03: GUI_Control:29 0x0

In gui-common.c, handle_common_events_startup, try using BGMT_Q_SET instead of BGMT_INFO.

Code: [Select]
diff -r eb5a09af2cf1 platform/EOSM.202/gui.h
--- a/platform/EOSM.202/gui.h
+++ b/platform/EOSM.202/gui.h
@@ -26,2 +26,3 @@
 #define BGMT_LV 0x1E
+#define BGMT_Q_SET 0x1D
diff -r eb5a09af2cf1 src/gui-common.c
--- a/src/gui-common.c
+++ b/src/gui-common.c
@@ -170,3 +170,3 @@
 #if defined(CONFIG_EOSM) || defined(CONFIG_100D) // these have a combined Q/SET button, SET button event is not sent properly
-        if (event->param == BGMT_INFO) { _disable_ml_startup(); return 0;} // don't load ML
+        if (event->param == BGMT_Q_SET) { _disable_ml_startup(); return 0;} // don't load ML

Very likely, the EOS M might be the same. The long-press trick for ETTR and other features might work too, as the button codes seem identical. To try this one (on top of the first patch):

Code: [Select]
diff -r 245c7831cc00 src/menu.c
--- a/src/menu.c
+++ b/src/menu.c
@@ -5977,3 +5977,3 @@
-#ifdef CONFIG_100D
+#ifdef BGMT_Q_SET
 static struct longpress qset_longpress = {
@@ -6155,3 +6155,3 @@
-#ifdef CONFIG_100D
+#ifdef BGMT_Q_SET
     /* triggers Q-menu by a long press on the combined q/set button */

Sure, a startup log with the SET button pressed.

Same for EOS M, please (or any other model where this feature is not working). If the feature is working, the startup log build won't save any log when you hold SET pressed (it will only save one when booting normally).

Indeed. It will still delay the boot process (loading from SD card takes time), will still reserve some RAM (likely nothing to worry about), will still run our GUI task (which hopefully behaves just like Canon's), but otherwise, all our hooks will be disabled, none of our "user" tasks will be started, so it's a lot less likely to be affected by a bug that way.

Implementation would be pretty much a dummy config preset (which can be configured to look at what key was pressed during startup). Difficult points:
- checking for that setting before initializing all the stuff (easiest to do by checking the presence of a "boolean" file)
- using file I/O before FIO backend initialization, or making sure that routine (and everything before it) is without side effects (for this purpose)
- deciding where to put it in ML menu (look up YAMLMO)
- compatibility checking on all models (hard, I usually get feedback from just a few camera models after few months)
- using the SD read-only switch (similar to CHDK) is also an option (without YAMLMO, but model-specific; testable in QEMU)

There is a possible side effect on models with CONFIG_AUDIO_CONTROLS, where Canon audio task is started after some delay (after the decision of loading ML or not was taking). It's not a widely tested code path, but it's likely harmless.

As a programmer...

In this case, the easiest way would be to just hardcode the desired behavior in boot-hack.c - negate the if (magic_off_request) - and recompile. Takes maybe 15 minutes (quoting dfort) to get started.

General Development Discussion / Re: ML UI rationalization
« on: March 20, 2018, 05:12:25 PM »
There was, but the interest in pushing it forward seems pretty low.

None of my cameras has touch screen, btw, so it will take a while until I'll get it working in QEMU.

Camera-specific discussion / Re: Canon 70D
« on: March 20, 2018, 11:49:12 AM »
Better, but for some reason, none of the registers changed with ISO. Did you take a picture before each log? The registers are *only* updated when Canon code changes them (when you actually take the picture, not when you change the setting from menu).

The module is not smart enough to detect whether you took a new picture or not.

Camera-specific discussion / Re: Canon 70D
« on: March 20, 2018, 11:12:57 AM »
It is relevant - it just adds noise to the dataset. Actually, the entire log contains only registers from LiveView.

No registers visible after enabling ADTG Registers, followed by taking a picture?

edit: yeah, forgot to mention - the registers are only updated when some Canon code changes them. In LiveView, that happens when entering LV, when switching video modes, and - for some registers - when changing settings such as ISO or shutter speed. In photo mode, the registers are only touched by Canon code when taking a picture.

So, you have to:
0) enable ADTG Registers
1) set ISO from Canon menu
2) take a picture
3) log register values (for that ISO)
4) repeat from step 1 for the next ISO

Camera-specific discussion / Re: Canon 70D
« on: March 19, 2018, 10:53:57 PM »
It gets close, but the image after conversion is not good (at least here).

Can you also log the register values in photo mode, outside LiveView, at each ISO?

General Development Discussion / Re: ML UI rationalization
« on: March 19, 2018, 10:40:36 PM »
Even if this thread is old, I think it's still the best place to discuss UI changes.

Suggestion under review: long-press SET/Q to open ML submenus on EOS M.
- advantage: using the Q button as on all other models
- disadvantage: long-press handling means short-press actions will be executed on release (slower feedback; I've found it unnatural after playing with it for a while)

- use the PLAY button to open submenus, in addition to Q (either only on EOS M, or possibly on all models)
- currently, this button decrements values for historical reasons, but I've never found myself using it... until Walter noticed it:

4.) Triangle icon. Used to start an action ("Play Button") and used show/hide menu options. Seen in MLV lite submenu: Playback will start playback and Advanced ... will show hidden items. Not that great IMO.

Another issue: many users end up pressing the MENU key and then they don't know how to go back.
Suggestion: disable the Junkie menu (anyone using it?) and just make the MENU key go back (until exiting ML menu).

Disabling the Junkie menu would save 4.5K of RAM (might be useful for e.g. 1100D).

MENU could also be reused for opening ML submenus, but that's a bit inconsistent with Canon menus (where it always goes back).

Lens info looks OK to me (matches the actual camera screen).

I had that lens mounted when getting the startup log for emulation.

Camera-specific discussion / Re: Canon 70D
« on: March 19, 2018, 04:53:43 PM »
Right, as long as the image moves as you move the camera, it's not broken (flicker is not a problem right now - that's just a resized version of an image with dark and bright lines).

You can see it better with Magic Zoom. The pattern might be stationary or "crawling" - on 5D3, this changes with FPS settings. I don't expect CMOS[0] to change this behavior, but if it does, please write it down.

Camera-specific discussion / Re: Canon 70D
« on: March 19, 2018, 04:48:31 PM »
At least 083 should be fine (since you have already posted valid Dual ISO samples from it).

General Development Discussion / Re: EOSM Shutter-Bug reboot
« on: March 19, 2018, 03:38:24 PM »
That's the area that I was experimenting with by putting in some msleep calls but it would just freeze on startup.

msleep only works after DryOS is up and running - long after that early boot stage. I've only tried it after calling Canon's init_task; might also work right before it, but it won't work earlier.

So is the LED activity indicating that it is writing to the card or is it also active when reading the card?

Generally speaking, LED activity is independent of card activity. There can be card access with LED turned on, card access with LED turned off, no card access with LED turned on and... no card access with led turned off.

For example, 5D2 bootloader reads from the card without ever bothering to turn on the LED.

To see the specific activity in some particular case, run in QEMU with -d io and look for SD/CF and LED activity.

Of course ML requires both camera and card bootflags set so maybe whatever is causing the shutter-bug might be in this very early lens initiation stage before the camera is even turned on?

Possible. Lens initialization (whether successful or not) might depend on the time it takes from physical power on until the MPU initialization (first mpu_send call, or maybe some subsequent mpu_send call). That's why I told you to place the msleeps on only one of the mpu_send_log calls - to verify this hypothesis.

I have a feeling the question was about the preview, where half-shutter toggles between real-time and framing-accurate. In this case, the option is in the raw video submenu (press Q).

FYI, sticky half-shutter does not come without side effects (locks up the GUI while it's sticky).

[...] photos on the homepage do not necessarily reflect the latest development.
Solved. Sorry it took so long - have fun browsing the menus on the home page :)

Now the screenshots can be auto-updated every time a new build arrives.

Continued here: Menu screenshots on the homepage.

Yeah, that counts, good catch.

Camera-specific discussion / Re: Canon 70D
« on: March 19, 2018, 09:42:45 AM »
Something I don't get: 083 worked before, but the first x5 picture in the set (assumed to be with 083) is black. Actually, all the 8.6MB pictures in groups #0, #4, #8 and #12 are black. Furthermore, pictures in the group #13 and #14 are not dual iso, and some of the pictures from the set have different ISO ratios.

#0 (13130002) => black
#1 (13130006) => 3.0EV, noise levels 5.99 14.93 14.86 5.82
#2 (13130010) => 3.0EV, noise levels 6.08 14.70 15.23 5.78
#3 (13130014) => 3.0EV, noise levels 6.21 14.74 15.15 5.83
#4 (13130018) => black
#5 (13130022) => 2.0EV, noise levels 7.10 14.95 15.26 6.94 => lower ISO increased from previous set
#6 (13130026) => 2.0EV, noise levels 7.07 14.96 14.95 6.96
#7 (13130031) => 2.0EV, noise levels 7.04 14.88 14.95 6.94
#8 (13130035) => black
#9 (13130039) => 0.99EV, noise levels 9.53 14.45 15.12 9.49 => lower ISO increased even more
#10 (13130043) => 1.0EV, noise levels 9.70 14.51 14.97 9.55
#11 (13130047) => 1.0EV, noise levels 9.67 14.76 15.31 9.49
#12 (13130051) => black
#13 (13130055) => 0.0EV, noise levels 9.82 14.77 15.20 9.57 (octave; image looks normal, cr2hdr refuses it)
#14 (13130059) => 0.0EV, noise levels 14.95 14.6 15.22 15.10 (octave; image looks like before, maybe with more hot pixels)
#15 (missing) => 0.0EV (predicted)

Previous sample:
13130002 => predicted 100/1600, got 4EV OK, noise levels 5.62 14.89 15.23 5.43

Image must be black if the two least significant bits are 0, unaffected otherwise.

Were the values in this sequence 0x083, 0x183 ... 0xE83, and was 0xF83 the missing one? If so, I'm unable to explain the results.
Were they 0x080, 0x081 ... 0x08E, and was 0x08F the missing one? If so, I can only explain the black frames and some of the ISO variations.

0x80      = 0b10000000 (predicted: black OK)
0x81/2/3  = 0b10000001/10/11 (predicted: 100/1600; got 3EV, expected 4)
0x84      = 0b10000100 (predicted: black OK)
0x85/6/7  = 0b10000101/10/11 (predicted: 200/1600; got 2EV, expected 3)
0x88      = 0b10001000 (predicted: black OK)
0x89/A/B  = 0b10001001/10/11 (predicted: 400/1600; got 1EV, expected 2)
0x8C      = 0b10001100 (predicted: black OK)
0x8D/E/F? = 0b10001101/10/11 (predicted: 400/1600; got 0EV, expected 1)

Assuming 0x60-0x6F to match the last two images, the predictions would be: 100/800 (3EV), 200/800 (2EV), 400/800 (1EV) and 800/800 (0EV). That seems to match, but why would you have chosen these values?

=> detective work failed; no idea what values you have set for this sequence. The sequence I've expected is 0x083, 0x183 ... 0xF83.

The FRSP images follow the same pattern (no surprises here).

That works, although each model needs some manual tuning (finding a suitable image, positioning buttons on top of it, working around model-specific quirks in the emulation...)

The old buttons (left/right) could be used for that. Adding this simulation to the download page, for each build, should be also useful (alongside with screenshot diffs to make it easier to identify the changes).

Camera-specific discussion / Re: Canon 70D
« on: March 19, 2018, 12:31:41 AM »
I ONLY changed the cmos 0 value, and left the 800c alone, thats what I was supposed to be doing and not changing them both, correct?

Correct, the 800c and the CMOS[0] are two different (unrelated) experiments. First is for 3x3 binning in 720p, second is for dual ISO.

The suggestion about higher bits comes from a quirk in 700D, EOSM and others, where these may result in 4 bright lines followed by 4 dark lines and so on. That weirdness mentioned by dfort looks fairly similar to that.

[...] photos on the homepage do not necessarily reflect the latest development.

Solved. Sorry it took so long - have fun browsing the menus on the home page :)

Now the screenshots can be auto-updated every time a new build arrives.

Under the hood:
- a script that navigates the entire ML menu and saves screenshots (it runs on Jenkins, here's a GIF)
  - the following modes are simulated: photo, photo LiveView, movie
  - for each top-level ML menu option: you can toggle the option (SET), navigate the submenu (Q) or do both
  - nothing can be changed in submenus (yet)
  - anything you have changed is discarded as soon as you go away from that menu item (to keep the number of screenshots manageable)
  - extras: Canon menu, Q menus (just navigation, without changing any option)
  - result: some pre-rendered screenshots (about 3000 images at the time of writing)
- some hardcoded navigation logic (that runs on the server)
  - simulation state is completely given by the key sequence you see in the URL
  - screenshots are served as static images like this (will be cached by your browser)
  - each screenshot has about 10K (LiveView screenshots are larger)
  - URL grows with each click (but you can start over from the power button)
- front-end (interpreted by the browser)
  - button overlays (the red circles) are SVG elements on top of the camera image
  - works with or without JS (looks nicer with JS, e.g. flips the movie button, LED activity, nicer transitions)
  - LED shows network activity (querying the next state, loading a screenshot)
  - keyboard works too if JS is enabled (same buttons as in QEMU); ESC to disable keybindings, ENTER to re-enable
  - browser back button works too

Camera-specific discussion / Re: Canon 70D
« on: March 18, 2018, 11:15:14 PM »
Yes, the pattern should be 2 lines bright and 2 lines dark (visible with Magic Zoom) and the image should look clean after conversion with cr2hdr (just like 5x and FRSP samples).

Camera-specific discussion / Re: Canon 70D
« on: March 18, 2018, 10:54:26 PM »
The 5x and FRSP images look like valid Dual ISO files; you may try converting them.

The 1080p sample is very interesting: one line brighter (at higher ISO) and one line darker (at lower ISO). That's the first camera doing this! (it has no practical use, it's covered in dual_iso.pdf, but it's interesting for understanding how things work)

Try playing with the higher bits, e.g. 0x183, 0x283, 0x483, 0x883 (or, if you have the patience, try all the 16 possible values, from 083 to F83).

The 720p one is pure black; no idea how to fix, unfortunately.

Pages: [1] 2 3 ... 382