Messages

Micro SD vs SD card, both are the same.  Real shooting experience.

There is no way for us to replicate what you are seeing because you don't give any information, so it's not useful to anyone.  If you list what cards you use, in what conditions, people could check.

It's a commercial product, why ask us?  Ask them, the website is listed and has a contact address.

Thanks for the appreciation

Work on older cams isn't wasted, ML tries to be a framework that allows the same code to work on many cameras.  It's harder to port to a new generation of cams so less people attempt it.  However, this is most of what I work on.

When new cams are added (e.g. see recent work on 200D, 7D2, R), features that work on old cams can be enabled.  This does require additional work, but less than if the features hadn't been made at all!

In that case, can you share me the right one

It's by design that module_strings.h is generated locally.  This is a slightly strange design, but that's the way it's supposed to work.  Giving you the file is not fixing the problem (and you already have the file, since you got it building on another system).

I have not given up. Just waiting for your inputs.

The problem here is that I want to fix this new error, but I can't reproduce it and don't have the time to install voidlinux and then hope I get the same broken config as you.  If you can determine the cause, I will fix it.

voidlinux has not broken in the last four years

I have nothing against bleeding edge distros - but I know from many years of experience that they are bad choices as build environments.  You will run into all kinds of difficulties due to cutting edge tools or libraries.  Essentially, you are asking me to support voidlinux as a build environment, and I don't want to, because I know it's going to cost me lots of effort for minimal gain.  You're choosing to use the weird environment, you have the responsibility to understand it.  I use Debian Testing or Stable.  For dev work, boring is good.

Personally I wouldn't recommend Ubuntu as a dev env, either, it's designed more for consumer usage.  Probably easier to get working than voidlinux though

The M build errors should go in a separate thread (you're missing some dev lib, possibly libc6-dev).

From the module_strings.h file it's clear that a) it has bad content and b) where the code must stop early in order to generate that content.  I couldn't work out a reason why it might stop there, it doesn't look possible to me.

Given I can't reproduce the problem and you've given up, I will too.  I'm glad you got it working, but be warned it's likely to stop working on voidlinux; these kind of distros are likely to update some library the binary depends on in a breaking way.

This suggests the content of module_strings.h is bad.  Please put the file on pastebin or similar and send me the link.

Didn't go well at all

I need more info than that in order to fix it

You've helped me find one real problem, which is now fixed for everyone.  If there are more problems remaining, we can fix those too.  This helps everyone who uses ML.

I have a binary that works for me, but that doesn't mean it will work on your system, because it's designed to load the libraries it was built against.  Yours will differ.  Sometimes this works, sometimes it doesn't.

Ah, good, we have found the real error:

Code Select Expand

modules/dual_iso/../html2text.py:630: SyntaxWarning: invalid escape sequence '\s'
  data = re.sub('\s+', ' ', data)

You are using a version of Python too modern for the build system.  A change in 3.12 has introduced this error:
https://docs.python.org/3/whatsnew/3.12.html

Code Select Expand

A backslash-character pair that is not a valid escape sequence now generates a SyntaxWarning,
instead of DeprecationWarning. For example, re.compile("\d+\.\d+") now emits a SyntaxWarning
 ("\d" is an invalid escape sequence, use raw strings for regular expression:
 re.compile(r"\d+\.\d+")). In a future Python version, SyntaxError will eventually be raised,
 instead of SyntaxWarning. (Contributed by Victor Stinner in gh-98401.)

Using a bleeding edge distro for doing builds may not be a good idea, you'll hit these kinds of problems fairly frequently.

Fixed: https://github.com/reticulatedpines/magiclantern_simplified/commit/09d3fddeb7f462d1dd61098e55abc1b81dd6433d

That shouldn't be relevant here.  You were trying to build an old repo that expects old tooling, and there was confusion around python2 and python3.

If zenny followed my instructions, they're using a modern repo that works fine with python3.

The only reason I've ever seen before for that error is missing rst2html from path, so I may not be able to help you much further.

When you're in the dual_iso directory, what's the output from this command?

Code Select Expand

python3 ../readme2modulestrings.py > module_strings.h


Do you have rst2html in path?

You will get an error around missing module_strings.h if you don't have rst2html in path.  On a debian based distro you can install this via:

Code Select Expand

apt install python3-docutils


Don't be surprised if someone tells you how to find MLVApp for Linux, if you say you can't find that

Assuming you're using a modern linux, to get cr2hdr I would recommend you do this:

Code Select Expand

git clone https://github.com/reticulatedpines/magiclantern_simplified
cd magiclantern_simplified/modules/dual_iso
make cr2hdr


It's worth noting that free space display works fine for 5D3 in my repo.  At some point in the heritage of Danne's repo, it was broken.

Thus, if OP is using Danne's, I view this as a bug with that code.

Do i need to update my Linux ? to the what is being used by you ? will i have problem compile my crop_rec builds ?

You need to work out why your system can't execute the python script listed in the error.

My repo has crop_rec code included.

For future reference, please don't post pictures of text - you can just paste the text!  I can't copy stuff out of an image to explain it or quote it.

That's an old linux distro, I don't advise it.  My repo will build cleanly up to gcc 13.  You can just use the distro gcc, no need to build a special one.

It's worth noting also that my repo has had very little testing on Digic 4 and 5 cams.  It's been used lightly on a range of cams with no significant problems reported.  But please do use some caution, and let me know if there are any new problems.

Here other post that references cf card sppeds & cf_acc hdparm

Thanks, I understand what's going on now.  This module is a port of the existing linux hdparm util so we can run it on cam.  How successfully, or how to even interface with it, I didn't look into   I assume the intent was to learn what control was possible over CF cards, then make nicer (and importantly, smaller) code to do the parts we care about.

The code is obviously quickly hacked up, possibly why it's in cf_acc module (which already existed).  That combined with it being a low-level linux util explains the refs to linux/types.h.

I've removed the linux specific stuff, here: https://github.com/reticulatedpines/magiclantern_simplified/tree/hdparm_hack

That should build more easily.  Because it's based on my repo, you can use a more modern linux.  I recommend Debian Testing.  It might not work on whatever old linux you're using, mainly because we converted everything to python3.  Try it and see if you want.

I haven't tested the code in any way.  Will it destroy your cam?  Maybe!

Sorry, I missed some of this as I was busy with digic 7 raw video.

You almost certainly don't want <linux/types.h>.  That's typically used for writing linux device drivers.  And we want ML to build on Mac and Windows, too.  You probably want <stdint.h>.  Swap that over and see if anything breaks.

You definitely don't want "LINUX_PATH=$(HOME)/src/linux-3.19".  That's just wrong.  Can you link to the source for this module?

Yup, it wants SD overclock!  I tried a bit, but the SD code looks quite different from older cams to me (but I have little experience in this area).  Certainly the logs during normal startup are different:

Code Select Expand


   962:   760.027 [SD] SdSwitchVoltage 1
   966:   813.315 [SD] SD initialize end speed=2 clock=2 UHS=1
   967:   813.361 [SD] strength 1111 current 3 mode 2


It knows about UHS, and it has parameters that look tunable.  I can see functions that do switch / case stuff and set registers in weird ways.  So I suspect it can be done, but I didn't get lucky finding equivs to the old registers in the few hours I looked

Zoom res check will have to wait, sorry - cam not connected now, and I'm going to be working on documenting EDMAC stuff for the next few days, so the next dev doesn't have to suffer as much.

200D raw video now works, using normal mlv_lite code.  You might find my changes helpful for some parts, on this branch: https://github.com/reticulatedpines/magiclantern_simplified/tree/200d_raw_draft
I'm expecting to change that branch before merging to dev, but not very much.

I can spend some more time on 7D2 if there are things I could do that would help?  I don't want to waste either of our time by duplicating work.

I've looked a little for EDMAC related stuff and it all seems to use RPC.

fe154724 is a function doing EDMAC stuff with Mossy, but very probably using RPC to do it.
fe255db8 might be CreateResLockEntry_RPC(int *, uint).  If so, d2000004 might be MMIO related to triggering the RPC.

I have however found something quite interesting and perhaps very useful.  I avoided the need to do a full edmac transfer on 200D because there's a convenience function that does a mem to mem copy using edmac region structs.  This is called in two places, some test code, and Vfx code.

Take a look at fe24ee8c - this function is Vfx related and has lots of mem to mem strings.  And it ends with a call to send_msg_to_Omar().  This might well be setting up for a copy that it's instructing Omar to run via edmac.  There are related functions around init and terminate Mem2Mem.  These also exist on 200D - but without RPC.  Since this is probably easier to understand than full edmac, and we only need mem to mem copies for raw video, getting this function working for us is something to consider.

Several years of learning ML code, trying to understand fragmentary docs, and in some cases writing the docs myself, 200D has raw video:

Bugs / quirks / limitations:
- only 14 bit is tested
- lossless modes are listed and definitely not supported, these should be hidden (this is a problem with mlv_lite code)
- mlv_lite has several hard-coded defaults that don't make sense for 200D (I think we need to make defaults detect cam model and choose behaviour intelligently)
- it records at 19.051 fps.  I have a few guesses as to why and will fix this
- 1280 * 720 is continuous, higher resolutions are not (200D SD interface is limited to about 40MB/s)
- MLV metadata is wrong in some places (bunch of stuff filled in as 0 or MAX_INT, it's a division by zero bug in ML code)

Code is available: https://github.com/reticulatedpines/magiclantern_simplified/compare/dev...200d_raw_draft
That's the changes compared to main branch; changes are fairly small!  This is a good place to look if you're interested in porting raw video to other Digic 7 models.

No direct links to builds yet, but if you ask in discord and have a good reason for using something that certainly hasn't been tested well, I might hand one over.  Otherwise you can wait till I've cleaned it up.

More cameras are in the works...

Nope, because I had no idea I should look there.  This code is really poorly organised.  There's different sensor size values in at least three different files, and they all interact.  Feels like a simpler system must be possible.  Why are some per cam values in platform/XXD, where you can find them, some are in src/random_file.c, where you can't, and some are in modules/random/random.c?  Ugh.

Thank you for coming back and teaching me this impossible ancient knowledge

The per cam stuff in raw.c should probably be moved into platform, right?

It's a code problem in mlv, not sure where yet.  It's producing an output file that claims to be 1920 * 1080, but contains data that is 2096 * 1164 (the correct size of the image).  mlvdump, and mlvapp, seem to be trusting the 1920 * 1080 fields, but filling the display from the 2096 wide data, so everything is the wrong colours and skewed.  I can see both values inside the file:


https://i.imgur.com/XR89GXZ.png

Time to learn mlv format and fix the code I guess.

If you never used IRC (or never knew that ML devs used IRC!), then you definitely don't need to care about Discord.  It is better for quick things, so feel free to use it if you just want to ask a question and get an answer (it's like WhatsApp or similar in this regard).  Can also do screensharing / voice chat, sometimes useful.

I like the 7D2.  Good build quality, metal body, even has weather-sealing.  It feels like an APS-C sized 5D3.  It's faster with card spanning than 5D3.  I'd recommend it if you see one at a good price

5D2 plans also make sense to investigate.  I'd especially appreciate somebody with more experience working with the hardware, who could try to verify my theory that the reslock structures are a linked list holding (block num, device ID) pairs.  If I'm right, it means the way ML locks devices is wrong.  So if some cams don't work the way they "should", that could be the cause.  And the read_edmacs[] / write_edmacs[] can be simplified quite a bit.  We might also be able to determine what individual devices are for - the current way we do this means we're using the wrong numbers!

Interesting HDMI strings   Good luck!

Separating out code / repo stuff.

Any help or advice would appreciated , i'm not big Linux user mainly PC(windows7 some windows 10 if i have to)
and some mac. its been about 3 years since i did any development so just need some refreshing 

The repo I maintain should work on old cams, and has many branches merged.  It contains crop_rec, lua_fix and other branches: https://github.com/reticulatedpines/magiclantern_simplified/commits

I mention this because some of the work I've done means this repo is much easier to build on modern systems.  You don't need to find gcc 4.8.  You can use any gcc from 8 to 13.  Ubuntu is an okay distro to use, Debian is better (this makes some things easier with qemu testing).  It compiles cleanly, with no warnings and no errors.  If any compilation warnings are introduced, I fix them.

Unlike the heptapod repo, I want to keep the number of active branches very low: only "dev".  All other branches are temporary, with the intention they will be deleted or merged into dev.  I found using heptapod very confusing - hard to find what you wanted.  Hard to know if a given branch would build, or what features it had.

I've also done similar work with qemu code, making this easier to build, and easier to run.  No patching things, no needing weird old versions of tools.

If you want to try this repo, I will happily talk you through how to get it working.  It is likely to become the official repo.  Nobody with access to the current official repo is active anymore, and making a working dev environment with it is difficult.