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 - names_are_hard

Pages: 1 ... 3 4 [5] 6 7 ... 21
It's normal for strace to show lots of ENOENT during a build, that in itself is not a problem.  The idea is to show where it's looking when it doesn't find them, to get a clue on how your system is configured.  Then we can try to find out what way it's badly configured.

The most interesting part is not strace itself, but this:
Code: [Select]
ml@ml-pc:~/CF_Card-Over-Clocking_magic-lantern/modules/cf_acc$ strace make zip

You shouldn't use "make zip" inside a module directory.  You want to run just "make".

Reverse Engineering / Re: UHS-I / SD cards investigation
« on: September 24, 2021, 09:40:21 PM »
Yay, problem sorted!  Turns out it was the commit I already suggested (but couldn't prove because heptapod didn't preserve commit hashes).

Not very relevant, but my mistake was guessing that "hg log b2db3dc9dd4f" would tell me about that commit (because searching for how to do this didn't get me any useful results...).  Instead it silently does nothing.  "hg log|grep b2db3dc9dd4f" does work.  Hg is weird and I'm glad I don't have to use it.

Reverse Engineering / Re: UHS-I / SD cards investigation
« on: September 24, 2021, 08:10:40 PM »
Huh, interesting.  Seems weird compared to listing the commit hash so you can lookup the whole thing.

Due to the forced repo change, the hash in this module can't be used to find the base commit.  So you get the diff but it's not that useful (unless there's some way to map Heptapod hashes to bitbucket ones?  Last I remember there wasn't).

My local bitbucket hg copy doesn't have the hash so I suspect this is some local branch of Alex's that never got pushed.  But I suck at hg so I could easily be doing something wrong.  Does hg sync everything?  I vaguely recall it doesn't so maybe there was a public branch but I never had it locally?

Reverse Engineering / Re: UHS-I / SD cards investigation
« on: September 24, 2021, 05:06:06 AM »
From strings in the mo file, it might be this commit:

Possibly it is based on that with unpushed changes.

General Development / Re: Dealing with Focus Pixels in raw video
« on: September 23, 2021, 06:55:30 PM »
Are you seeing this in Liveview only, or do you see them when you play back recordings?  It is normal for focus peaking indicators to show in liveview (they should not be recorded).  Also, focus peaking is not the same things as focus pixels, so you're asking in the wrong thread ;)

General Chat / Re: rtemote control/focus stacking et al...
« on: September 19, 2021, 05:54:06 PM »
"Faking" the cable trigger is really easy, which is probably why that's recommended.  It's a standard connector and you just need to bridge two wires, so you can attach it direct to GPIO.  I wouldn't expect you'd want to change camera settings per shot for a stacker?

If you can be more specific about what you hope ML might help with, we can give a better answer.  You certainly can use ML to take a picture.  You can control many cams, including Canon cams, via PTP, for which there are libraries available.

Okay, so you have at least one version installed.  But it's not the one the compiler is looking for.  Could be 32 vs 64 bit, could be amd64 host vs ARM target.  You could use strace to determine where it's searching, which might give you some clues.  It will produce a lot of output, redirect it to file or filter it.

Search using your package manager.  This differs per distro.  If you're using an apt based distro, you can do this:
Code: [Select]
apt search linux-libc-dev|grep linux-libc-dev|grep installed

It's looking for a system header.  Probably should be at /usr/include/linux/types.h.  Do you have linux-libc-dev installed?

crop_rec and derived builds / Re: Danne's crop_rec_4k, 5DIII
« on: September 10, 2021, 12:13:14 AM »
GullRaDriel - walking you through building a repo is probably better suited for Discord.  You're likely to have a few problems along the way and it's slow fixing them one at a time on a forum.  I can walk you through build problems.  I don't know if cygwin works.  Debian definitely does, I use that.  Pretty sure WSL is known to work also.

General Development / Re: Translating Menus
« on: September 04, 2021, 06:18:01 AM »
Changes are surely very rare :)  I think the way you're doing things will work well in practice.

I do think it would be cleaner if the module only contained the strings for the language, perhaps in an array.  You could have it so every language is a module, including english.  Default build would include english (and I guess language modules would need to be exempt from the "modules don't load if you crashed" logic; or, keep english non-module and it would revert to english if modules didn't load).  Add other modules if you want.  Have a ML menu to swap languages.  Change the main code something like this:

Old code:
Code: [Select]
bmp_printf( FONT_SMALL, 0, y, "Config: %x", (unsigned) global_config );

New equivalent:
Code: [Select]
bmp_printf_localised( FONT_SMALL, 0, y, LOCALISED_CONFIG, (unsigned) global_config );

bmp_printf_localised() looks up the string by the index in the array (LOCALISED_CONFIG would be the index in the array of "Config: %x" in the english array).  That gets passed to bmp_printf().  It's not a hard change, although it is a lot of small changes.

General Development / Re: Translating Menus
« on: September 04, 2021, 02:26:32 AM »
It would be a fair amount of work, but localisation tends to be.  With how you have it currently, if anyone changes the english menu text, your match might break, and then it won't display correctly, right?

General Development / Re: Translating Menus
« on: September 03, 2021, 09:57:32 PM »
It's cool seeing the menus in a different language, definitely a good feature to have!  Longer term it might be better to have this in the main code, not a module?  I'm not sure, there are pros and cons.  I suspect it makes most sense that the strings aren't in *any* language in the main code, but instead are referenced by index.  Then you can swap languages in and out easily, by having multiple arrays of strings, one per language, and printing by index.  This is more work but more generic.

Re Arabic characters, kitor did some good work allowing loading fonts from card.  We needed this for modern digic because those cams don't have a bitmap font in rom.  I wrote some scripts that allow converting existing BDF fonts into the Canon format.  So there's a route there that could work.  For the modern cams, they have hardware accelerated font display, using some scalable font format (TTF?  Not sure, some standard, vector format).  These are in roms and likely have many languages (it's what normal Canon menus use), but a) old cams don't have this and b) we don't know how to draw with this yet (looks fairly easy, not tried it).

Camera-specific Development / Re: Canon 750D
« on: August 27, 2021, 01:56:22 PM »
Saying that the devs don't care is rude and uncalled for.  Posting the same rant three times makes the forums worse for everyone else.

It's not a conspiracy against you.  If no dev has a 750d, nobody is going to port to it.  There aren't many devs, you got unlucky.

Insulting the people who might give you something for free is not a sensible plan.  Here are some better options:
 - sell it and buy a supported cam (quickest, easiest)
 - port it yourself, you've had 4 years so far to learn how (most rewarding)
 - send it to me, I'll port it (slow: I guarantee I will work on it, I give no guarantee how long it will take)

Camera-specific Development / Re: Porting ML to XSi (450D)
« on: August 07, 2021, 11:44:55 PM »
Okay, in that case definitely look at the commits I linked.  ML does shell commands in various places that explicitly call hg CLI commands.  It is not possible to automatically convert it, the problem isn't the repo using git or hg, the problem is ML build system tries to use hg tools, and expects hg related directories to exist.  You must modify the build system if you want to manage ML code using git.

The commits I link to make those changes. 

Camera-specific Development / Re: Porting ML to XSi (450D)
« on: August 07, 2021, 09:09:10 PM »
Looks interesting, but it's hard to understand because there is not much context.  This is a fork of some other repo?  Which one?  The commit history has lost everything from wherever it came from.  It's not forked from mine because platform dir doesn't have any Digic 6, 7, or 8 cams.  It would probably make more sense to have these changes on a branch of an existing repo, so that history was more meaningful.

You have a .gitignore file at top level, but official ML is hg managed - that's why you're getting these errors.  You've probably taken this source from some git managed repo?  The build process expects to use hg tools at a few places.  Personally I think making the build process dependent on the source control system is not a good idea, I removed this in my repo so you might be able to adapt those changes:

Those changes might not cover everything you need, it was over a year ago and I wasn't very familiar with ML code yet, changes are more likely to be messy.  Check commits around the same time.

Progress continues.  Free Mem work uncovered some complicated problems with SRM allocator that took a while to get tamed (Kitor helped a lot here, thanks!).  For now, we have disabled this allocator on D678 (couldn't get free() to work correctly, which causes crashes due to SRM being a LIFO allocator).

Due to bumping up against the ML reserved memory limit, I worked out how to steal more memory from DryOS in early init.  ASCII art summary here:
This works well on the cameras we've tested on (200D, R, RP, M50 I think, maybe not all of these).  We have enough memory now that we can have multiple features enabled, plus I made it simpler to adjust how much is being stolen.  But a downside is that it requires changes to stubs.S for other D678 cams in order to build.  That means I have to do some reversing work on every other D678 cam, or split the cams so some use the old system.  I'd like to avoid the latter option as the solution should be general, and splitting would make the code quite a lot more ugly.

Separately, I got task info working.  This required tracking down some changes to task related structs (task_attr_str).  And fixing a bunch of null pointer derefs in ML code!  Digic 4 and 5 cams don't crash on null pointer derefs, but D678 ones do, due to MMU settings...  I'm sure there's lots more of that fun to discover.

Next up is finding something acceptable to do with new memory stealing on the other D678 cams, then getting Qemu regression testing working locally, so I can have some confidence that changes to support new cams hasn't broken old cams.  I think it's likely this will expose some problems, my repo is a poorly tested merge of several important upstream branches, these will then need fixing.

Camera Emergency Department / Re: [UNBRICKED] Bricked 60D Err 70
« on: July 31, 2021, 04:51:59 PM »
I would keep the cam able to run ML, that allows running diagnostic tests.  I read the logs but didn't see anything obvious to me (I don't have experience using these logs to diagnose HW errors, only software).

If you are confident about removing the case to check for loose or disconnected cables, it might help.  If you don't feel comfortable doing this, then don't.

Camera Emergency Department / Re: [UNBRICKED] Bricked 60D Err 70
« on: July 31, 2021, 03:06:06 PM »
Err 70 is a Canon error code for a wide range of problems, often caused by hardware failure.  You don't say, but I assume you have these problems with or without ML.  If you are using third party hardware (lens, flash etc), try without those attached.

I don't have much experience troubleshooting Canon HW problems, but you seem to have multiple problems at once.  Possibly a loose cable inside?

Don't know why I had it in my brain as hours, seconds does make a lot more sense!  Basically, for the RP, we don't really know what these numbers mean.  There are some fields where we can make some obvious guesses, and likely be right, but that's about it.

Don't recall which precise field it is for 200D, point being, it was negative so I don't put it past them to apply a negative offset to one of the other fields (plus code for some existing cams already applies a fix for this, I've seen it somewhere).

Okay, but your comments about different cams, in a Digic 8 and X thread were confusing and don't seem relevant.

From this thread, there are numbers from multiple different cams.  All TotalShutter numbers look to have a similar large offset applied.  But, does TotalShoot have a different, *smaller* offset applied?  How would we know?  It's a reasonable assumption that TotalShoot might start at 0, but TotalShutter *clearly doesn't*, so it's also reasonable to doubt that assumption.

Cam1 TotalShoot: 1780
Cam1 TotalShutter: 1086948659

Cam2 TotalShoot: 701
Cam2 TotalShutter: 1086947603

From these numbers it's still entirely possible that RP has an offset of 700 applied to TotalShoot, similar to how it seems to have an offset of approximately 1086947300 applied to TotalShutter.  If that was true, j1080s cam would have taken 1 prior shot.  Or there could be no offset, and it's taken 701.  Or an offset of -10000 and it's real number is 10701.  Notably, my 200D (bought new...  probably) reported a negative TotalShoot when I first had it!

Likely it will be easier to reverse the firmware to determine the logic, than to prove we have a new cam where we can totally trust the values.

Oh, I understand now, you were talking about something different to everyone else in the thread.  Now my confusion makes sense :)

I would assume that the goods were returned. ;)

With 1,086,947,603 shutter activations?  This seems somewhat implausible to me, though perhaps you're a faster shooter than I am before you return a camera ;)

I also think this camera is likely gently used and returned, but that doesn't explain listed shutter count on RP.  Something else is going on.  This camera is different in some way with the way it reports this value.  Running time is also obviously incorrectly reported.  So, can we really trust the other values, even though they look sensible?  We just don't understand this camera very well yet.

It's a reasonable expectation, it also happens to be demonstrably untrue.  What does it mean that new RP don't show 0 via this method of querying it?  We don't yet know.

We don't know much about RP yet, nobody can give you a definitive answer.  How much do these values go up on every cam due to testing Canon does in the factory?  We don't know.

The TotalRunningTime cannot be correct; that would be 5 years continuous running for yours.  Someone else was reporting 50 years.

Pages: 1 ... 3 4 [5] 6 7 ... 21