Messages

no problems with 70D here for the past 6 months trying 2015 q1 / q2 gcc from launchpad. maybe related to digic4?

Must be *something* that works with 4.8 but not 4.9 on the 60d, so maybe really some digic4-stuff gets mis-compiled. Not that important, it's just a ~20k smaller binary with the newer gcc - since the memory issues have been resolved, I'm not that much into optimizing for size but rather for speed.

did you already try to redefine the path to libc.a in makefile.user.default. It points to ml source dir by default.

Um, never heard of that idea. What are you talking about exactly, the only libc.a I see in makefile.user.default is the "NEWLIB_LIBC_A=$(NEWLIB_PATH)/libc.a" which indeed does end up in the src/libs dir - but where should I point it to instead?

Just to spare all you good people some trouble and b/c it might be the natural inclination of the hardware hacker to use bleeding edge software, too...

... the latest gcc 4.9.3 (from launchpad) breaks my 60d build, the led activates on boot and that's that. It's working just fine though with gcc 4.8.4, so some new optimizations don't like the ml source or there are some bugs in 4.9.

Strangely, compiling the very same source with 4.9.3 for *6d* works just fine. Go figure :-p

Everythings works as it did before.

Yippeee! Clap your hands for the work of Maqs and JLGW! And thanks to Alex for clicking the "Accept pull request" button! Popcorn! :-)

Thanks ! I would love to see the focus patterns feature.

I guess there's no end to potential little helper functions and features (button-feature mapping and simple if-then). It's clear that for every feature desired by one user ten more will pop up deeming it unnecessary and are against merging.

Thus problem is how to integrate 'em all in a general way into ML: it's either via a big usability module with a huge workload on the gui interface or with user scripting. At least with the latter there seems to be hope again looking at the lua branch. If there's a good api to the ml features, you might be able to write most simple automatizations yourself w/o coding C.

Note that in this context it isn't well placed in a 6d thread anymore.

Sometimes there is a need to switch from Tracking focus to Single, and temporary switch between two can be set to hotkey.

I'd appreciate a feature that also switches focus points from Auto when Tracking focus is active to Center Point, when OneShot focus occurs.

Or make independent FP choice as it is done in vertical/horizontal orientation..

Can it be implemented in ML?

All these three things could be implemented by ML, the core code is there so you just need the logic to do "if button x is pressed do this" or if "level changes do that" or "if one-shot focus do thisandthat". Seems it's time to learn how to code a module for you :-)

Before I have a 1.1.3 but with an another name ... Now I have updated to the 1.1.6 provided on the official Canon website support.

Interesting, I'd like to know if it's some hardware change on your specific camera that enables this menu or a flag in the nvram. I've asked on CR, maybe someone happens to know over there: http://www.canonrumors.com/forum/index.php?topic=26242

* Marsu42 now also runs 1.1.6, works fine though I'm just using a subset of ML features atm. Thanks to Maqs and JLGW for all the work, it's hilarious tedious it is to get ML from one minor fw version to another

Imho it's time to push this to the main repo, get it merged and do nightly 1.1.6 builds before 1.1.7 is released :-p. If nobody complains, I'd even vote to dump 1.1.3 unless major problems with batteries being blacklisted by Canon pop up. I guess most people will want to run the most recent fw and downgrading just to make ML work preventing some to try it.

I have a factory firmware with a Factory Menu but I'm not able to change it. If you want some info from this firmware tell me.

Ugh? So this firmware of yours works with the 1.1.6 ML port, but contains this additional "Factory" menu? What does it contain, and what does "not able to change it" mean exactly?

At the moment, the only problem left seems to be something with StopASIFDMADAC (will ASSERT and then show ERR 70). Seems to be some semaphore thing, not toooo difficult I hope.

An assert getting in the way :-p ... that's exactly what 1% patched out in his TL build :->. He didn't find a way 'round it, I hope you have more luck as this is definitely outside my scope of expertise.

If I'm not mistaken the 6D gains almost nothing from 116, but loses 3rd party battery support, which is my main resistance to updating. As far as 6D users interested in using and testing ML, we are out here, maybe just not all of us  are ready to switch to 116 and give up our 3rd party batteries.

* You're mistaken, 1.1.6 contains a critical fix (if you're hurt by the bug) for tracking with all af pts as lower fw versions tended to ignore the center point. I'm a victim of this absolutely hilarious and annoying behavior, that's why I need to update.

* As far as I've read the posts on CR discussing Canon's battery game, only old or non-chipped batteries are sanctioned with an annoying message - but if you've got a newer clone battery with a chip it should still work. Actually the battery charger is more likely to refuse 3rd party batteries than the camera atm.

Do not expect all sounds to work properly (the mp3 player and beep testing does, but arkanoid crashes) due to some problem I'm trying to investigate. Also let me mention that new-sound-system is no "productive" branch and you may find other problems with it.

Well, a lot of stuff stuck in branches is probably working 99% and isn't merged for missing the last 1% (no pun intended to the former TL author :-)).

Thanks for looking into the sound system crash, but it could be difficult as no dev around here has a 6d and will be able to help you - I faintly remember the 6d using some rather exotic sound chip? I'll wait for you reporting back here on this.

> The port is working fine here, but there's about no feedback from testers so far. :-(

Well, yeah, that's ML development for you - esp. with a camera with an incomplete port and "blindly" maintained there won't be a lot of folks here using it. But now that beep works I'll switch, but not in the next few days but more like few weeks.

> No need for any cache hacking here - just merge in the new sound system, uncomment "#define CONFIG_BEEP" in internals.h and it can beep

Great news, thanks! I knew the new sound system was working on it, but didn't realize it was already working as the last commit in this branch is months old and usually things only work on 5d3 first and then filter down to 6d eventually.

Concerning the 6d.116 port: Thanks maqs & jlgw for the work (even double the amount :-p).

1. It would be nice if both attempts would be merged, jlgw looks a bit more complete right now (including the stub for SetAudioVolumeIn), but maqs has some patches for modules jlgw doesn't have. Here's the wrap:

https://bitbucket.org/JLGW/magic-lantern/branches/compare/6D-116%0Dunified#diff
https://bitbucket.org/Maqs/magic-lantern/branches/compare/6D.116%0Dunified#diff

2. Personally, I won't use 1.1.6 until it can beep() - can it?

Otherwise (even if Alex will cry out in pain) it needs an update to 1%'s cache hack, I'd rather have some odd err70 crash now and then if multiple beeps occur in quick succession than having no beep at all as I rely so much on it for blind camera operation. I know this won't make it into mainline ML, but for personal builds it's better than nothing.

There is 1%'s source mod for 1.1.3 with his run_hacks() (see https://bitbucket.org/OtherOnePercent/tragic-lantern-6d/src/05b95b89c05e/src/beep.c) which probably needs some updated HIJACK_ addresses (see https://bitbucket.org/OtherOnePercent/tragic-lantern-6d/src/a2952db9d4dfb0180f61eb596741b251991c9b2a/platform/6D.113/consts.h?at=unified)

Ah, add a dummy prop handler somewhere. Without it, ML doesn't know the correct length of the property, and refuses to change it.

Right, now I understand how ML checks these in the first place. Pity we don't get this information from the sdk our favorite imaging company gladly supplies to their users :-p. Will do, but this time really on my 60d after I dig it out somewhere.

Code Select Expand


volatile PROP_INT(PROP_PIC_QUALITY, pic_quality);
volatile PROP_INT(PROP_PIC_QUALITY2, pic_quality);
volatile PROP_INT(PROP_PIC_QUALITY3, pic_quality);


Edit: Btw: Compiled these with gcc 4.9.3 (from launchpad), work fine & smaller file size for what it's worth.

1. That's what I thought back then. I took a closer look in Canon code - it appears to set all 3 of them, and from GUI_SetImgComposition, the first property seems to be for drive A (CF), second for drive B (SD), and third for drive C (WFT maybe).

Good idea, I'll use my 60d for further experiments (the shutter is near failure due to >150k anyway).

I just tried on my 6d, and that's the result:
* if setting only the first prop, it resets just the ML gui display value (raw/jpeg/...) but the actual Canon value remains unchanged.
* if setting all three props, it complains about wrong len - probably only 1+3 exist on 6d since it's missing the cf slot? Thank the maker for these safeguards because these are just the messages I *don't* want to see on my precious 6d

Code Select Expand


ML ASSERT:
PROP_LEN(80000030) correct:0 called:4
at ../../src/property.c:342 (prop_request_change), task tweak_task
lv:0 mode:1

Magic Lantern version : v2.x.M42.2015Jan05.6D113
Mercurial changeset   : caa55c6fce2c+ (unified) tip
Built on 2015-01-05 20:54:22 UTC by USER@CYGWIN.
Free Memory  : 381K + 1864K


ML calls functions in the Canon firmware by hardcoded addresses. These addresses can be different in different Canon firmware versions. So if you want to use a different firmware version, you have to decompile the Canon firmware, and find the addresses all over again. This is a lot of work.

I'd also like to see a 1.1.6 fw ML update, but I won't do it either :-p ... searching for changed stubs is probably one of the most stupid tasks, and then you have to check if Canon didn't change something under the hood.

Unless there are really killer features, I doubt it that it's "worth it". The multi-point af center pt fix is important, but it doubt any software upgrade can make the 6d better at it as the outer points are non-cross and simply give inaccurate information to the fw. Or did any 1.1.6 user notice a real improvement?

Thanks for the quick reply! Before I go ahead (and report back):

1. Do I have to set all three props (yes, I know, all are included in set_pic_quality) or just the one that is read when looking what mode is set?

2. Does a C mode safeguard against soft-bricking with changing this prop? I wouldn't like to have to unbrick my 6d esp. as there are no active devs around who can help me out if it doesn't work as the other/older models.

Yo, after managing to set my 6d to m-raw for some important shots (I didn't notice the warning, even though it was enabled) I'd like to add the option to *lock* the camera to raw mode, i.e. extent the feature in tweaks.c

Problem is: setting PROP_PIC_QUALITY seems like a premiere way to brick the camera, I guess thus the feature name "FEATURE_PICQ_DANGEROUS". I don't know if a "C" mode is a foolproof safeguard at least for testing: http://www.magiclantern.fm/forum/index.php?topic=5100.0

The ML code contains the function to read the prop and figure out if raw is enabled, but how do I *set* raw - or is this not possible in a reliable way at all? Did anyone succeed at least on the current gen bodies (6d,5d3), how did you do it?

I'm currently reading heavy into the general dev discussion to get my bearings, and hopefully I'll have a sensible workflow before long, but any advice you can give to a n00b is much appreciated 

Great to hear you're on the 6d, coding most ML stuff is not that difficult *but* you have to find your way through the code first and get an impression how the Canon fw does things (props. av/tv/iso values in 8-steps, ...). Then most things just take a lot of time: finding stubs, testing alex' modules, wrestling with small incompatibilities.

For me, the thing I had to learn is that coding for ML works best "en block" without interruptions, or I forget too much about the whole thing again. You also have to be motivated enough to swap the sd card every other minute from camera to computer to test new code and have to live with very basic log/info box debugging which is not ideal for many cases. A good frustration tolerance certainly helps.

Last not least, it takes a loooooong time from the "works for me on my camera" stage to polish code enough to run on *all* models and have a nice and cozy gui. You'll learn that once your code is in the bitbucket pull request queue, open for comments :-p ... I admit this is usually the stage where I stall because if it "just works" I'd rather get out and take pictures than continue to sit behind a screen.

Does anyone here know if ML works with 6D(n)?

I'd guess "yes" because they seem to share the same firmware, the crippled version just lacks some hardware so supposedly the fw detects this and just disables/hides the according menu items.

The GUI part can be simply the first feature enabled being left enabled, and the second one grayed out, with an explanation (you need to turn off XYZ or whatever). So, you'll notice it right away when you attempt to enable a conflicting feature.

Ok, might be the simplest solution, though you'd need to really search for dependencies when learning ML and it gets complicated if there are chain dependencies a disables b disables c. If the dependencies are in a table somewhere anyway, probably printing them in the Q help menu screen might be feasible - as there are nearly no docs atm, it the help might look less empty :-)

So, a conflict handler may be interesting in the menu backend or even in the config variables

+1, that sounds like a sound proposal, though there should be some gui backend asking the user which of the conflicting features to enable or at least clearly notify about what is about to be turned auto-turned off to prevent conflicts.

I have 6D, and I am up for any kind of test/build you want to test.

Ok then please do this (iso sequences with raw_diag):

http://www.magiclantern.fm/forum/index.php?topic=10111.msg117955#msg117955

and this (shoot test charts for silent zoom bracket test):

http://www.magiclantern.fm/forum/index.php?topic=10111.msg118232#msg118232

Anyone heard any news on dev so far? Who gets to be the first guinea pig?

Afaik as the ML code base is very stable by now, hard bricking is very unlikely even on new ports - and soft bricking can be avoided by not writing props to nvram in the first builds.

What will need testing (same for 6d) are the small things, does this feature work 100% or only 70% or only in some cases? Why does only model xyz show this behavior and not abc (i.e. why doesn't this key respond on 70d even if it does on 60)? This is what takes really time and systematic work from bare metal "Hello World".

Everybody knows 6d is not good for video.

Video? Why would I do video? What's video anyway?

I did see that it is broken for the last weeks, is this gonna be fixed, I believe Alex is the only one with a 6d right ? (Besides 1% who has it's tragic lantern)

Nope, alex doesn't have got a 6d and doesn't want one. 1% seems to be still around somewhat, but doesn't update his TL repo anymore, I guess he now keeps his 6d patches to himself after the recent commotion.

There are some users who can code to some extent around, but no one seems to be willing or have time to volunteer as a 6d maintainer.... so I fear that once there will be some ML refactoring or other in-depth changes the 6d will be left in the dust. Alas, as you said, it's "usable" now so it could be worse.

I'm very happy with it 

Me, too - but question is if any upcoming features (like mini_iso extended dynamic range, patch manager used in dual_iso, new audio system) will be ported to the 6d w/o anyone maintaining it. Currently the nightly 6d build is broken due to changes in the fps override - contrary to what you wrote, alex stated that it doesn't really work (I haven't tried myself).