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 2 3 [4] 5 6 ... 21
General Help Q&A / Re: Canon 700d HDMI out Issue
« on: February 02, 2022, 12:15:23 AM »
You're unlikely to find someone with the same combination of camera and capture card.

Does it matter if anyone else has seen it?  The problem seems to be the capture card.  I'd recommend trying another one.

Camera-specific Development / Re: Canon EOS 1300D / Rebel T6
« on: January 13, 2022, 04:36:51 PM »
This confused me enough that I had to look it up.

The 1300D *does* have a Trash button.  It doesn't have a dedicated Trash button, it shares the same button as AV.

General Help Q&A / Re: Canon M50 Mark II
« on: January 02, 2022, 06:37:24 AM »
M50 and M50 mk2 are different cams from EOS M.  There is not yet ML for M50 or M50 mk2.

Camera-specific Development / Re: Canon 850D / T8i
« on: January 02, 2022, 01:59:55 AM »
Got some features working (also on 200d).

Shutter count zero appears accurate for 850d:

Benchmarks and screenshots work (not all benchmarks tested):

They work fine for me.  Can you give an example link that doesn't work?  Thanks.

Camera-specific Development / Re: Canon 5D Mark IV
« on: December 24, 2021, 05:36:45 AM »
No, there is no real ML for 5D4.  We have a partial version that boots and does some early stuff, but there's still lots of debugging work needed.  No devs have access to 5D4 so don't expect any progress.

Camera Emergency Department / Re: Eos 550D doesn't work with SD card insert
« on: December 10, 2021, 03:54:21 PM »
You can use imgur.  Upload there, get the raw url for the image, use that inside img tags (remove \, can't get it to display nicely): \[img\]http://[/img]

Camera-specific Development / Re: Canon 70D
« on: November 27, 2021, 05:15:12 AM »
Bilal, over to you :)

Camera-specific Development / Re: Canon 70D
« on: November 26, 2021, 04:47:00 PM »
Which build are you using?

Camera-specific Development / Canon 850D / T8i
« on: November 26, 2021, 04:28:37 PM »
I was taken by a fey mood, and have produced this:

This was my first time porting to Digic 8, and it's a bit different from the existing Digic 8 cams I've looked at.  There's a very important change to early boot process that was hard to determine, initialising the second core has changed.  Everything else seems normal enough so far, Kitor helped with the Ximr stuff, it seems to be closest to RP.

Dumped the roms with Basic.  Works well enough in Qemu to test the very early code, although Qemu will need updating due to the boot process change, MMIO addresses are used differently and Qemu assumes all D8 will be the same.  I haven't tried UART yet but the connector is under the thumb grip as is common on modern cams.

I don't recommend anyone try to run this yet, but the source may be useful for people looking at other D8 cams:

Buttons aren't mapped yet, graphics don't display how I'd expect, etc, lots of other bugs I'm sure.  I'll try to improve it to the same state as 200D.

General Development / Re: Canon Basic scripting (DIGIC 8, DIGIC X models)
« on: November 26, 2021, 04:06:49 PM »
Canon Basic dumper confirmed to work on 850D.

Camera-specific Development / Re: Canon 70D
« on: November 25, 2021, 06:15:13 AM »
Source code for what?

All D678 cams can now use the same improved mem stealing logic.  This means one less file to maintain, plus more memory for ML.  This was fairly complicated work and I had to update every cam after confirming stuff in roms.  Kitor had a nice idea on how to simplify one part of this process that reduces what you need to find on new ports, as well as letting me make the code cleaner.

Implemented a mechanism for allowing limited PROP_REQUEST_CHANGE so we can safely experiment without enabling all props.

A bunch of small improvements to the build system to remove some annoyances, and a major fix that removes a significant race condition with parallel builds.  The "minimal" subdir builds were clobbering files during build, causing "make zip" builds to fail randomly.  Was quite annoying to track down.

Found initial stubs for 6D2 builds, should be easy now to get what we have running on that cam.

Generally, a lot of boring but useful work that is applicable to all D678 cams, not just Digic 7.  There's some small bonuses as well, you can check the repo if you want to find them.

Special thanks to kitor and coon who have been quite active lately doing a lot of good work, checking my stuff, talking ideas over, as well as doing their own work and merging in.  I'll let them talk about their own parts!  Between us we're doing well keeping all the things we add working across D678.

We even have a few possible new devs in Discord, who will hopefully stick around!

General Help Q&A / Re: Farewell 5D3
« on: November 06, 2021, 04:57:11 PM »
5D3 is a great cam, and you got a lot of use out of it, do not be sad!  R has a good, active dev, so you made a good choice on the replacement.

Camera Emergency Department / Re: EOS 60D Dead
« on: November 05, 2021, 02:51:09 PM »
Yes, one of the reasons for saving the roms is that in *some* situations, flashing back some data (e.g., known good cam settings) can help.  However, I have no experience of how to tell when this should be done, and I don't know precisely how to do it.  I know roughly how, in theory... I have no practice at this and don't want to try it blind on someone else's camera and make the problem worse.

Also - the failure may be entirely unrelated to the roms or ML (this has been true for most people reporting dead cams).  Your cam is getting far enough in the boot process that diagnostics and logging is the right next step.  It could be that something physical died, e.g. the power switch.

Thanks for the offer.  We have an active dev with EOS R, but there is nothing that needs testing.  6D2 doesn't have a dev working on it, so, again, nothing to test.  Later on you could maybe help porting by doing tests on 6D2, but I think all devs are busy enough for now that they won't have time for that.  I'll let you know if I'm wrong!

Well, I answered your original question: the error message can have multiple causes, and they are complex.

It sounds like your actual problem is more likely something in DualISO than ETTR.  Maybe some interaction between the two?  I don't have any direct experience with either of these so I can't help, sorry.  If you know a little C you could add some logging.

Checking the source, there are a variety of possible causes.  The relevant code is in modules/ettr/ettr.c

There are some early ways to hit this error, shown here (similar in auto_ettr_on_request_task_slow()):
Code: [Select]
1122 static void auto_ettr_on_request_task_fast()
1123 {
1124     ettr_beep();
1125     int raw_requested = 0;
1127     char* err_msg = "ETTR failed";
1129     /* requires LiveView and ExpSim */
1130     if (!auto_ettr_prepare_lv(0, 1)) goto err;
1131     if (!auto_ettr_check_lv()) goto err;
1133     if (get_halfshutter_pressed())
1134     {
1135         msleep(500);
1136         if (get_halfshutter_pressed()) goto err;
1137     }

There are some later ways too but that's too complex for me to try and list.

Sorry, don't have a Mac, so I have no way to test.  I don't see any other mistakes, but I try and avoid using shell scripts, because they are hard to debug.  So I'm not very good at them.

In the Mac attempt, you are using a variable uninitialised, here:
echo "0000068: FF 3F" | xxd -r - $file

Replace $file with $f.

Bash will happily replace variables that don't exist with an empty string.

General Development / Re: The MLV format
« on: September 30, 2021, 09:54:22 PM »
Forking from an earlier version doesn't sound ideal if ML is using the more recent code in its MLV files - won't that cause incompatibility?

MIT/BSD vs GPL is an interesting argument vs adoption.  Companies are more wary of taking GPLv2 code, but, if they take MIT/BSD code, they don't tend to cooperate with upstream - there's no need.  They're also allowed to modify your code (making incompatible MLV files) and not share those changes, which would suck.  Linux is GPL and Intel contributes driver code to them directly, for example, because GPLv2 means that's easier for them and it means Linux servers buy more Intel kit.

If MIT/BSD always lead to wide support, why is Linux so much more widespread and better supported than the BSDs?  GPLv2 was the right license to get Linux widely used and supported.

You could always license it as GPLv2 for now (because it's easier), but, since you retain copyright on the code you write, change the license on that code later on.  Sames goes for MLV if you get permission from the copyright holders there.  This is pretty common, having dual-license available on request (for a fee for the non-GPLv2 version, if you want).

General Development / Re: The MLV format
« on: September 30, 2021, 08:52:59 PM »
The mlv.h I have is licensed GPLv2, not LGPL.  Which version of mlv.h are you working with?  GPL does not have the linking exception that LGPL has.

My personal, not-a-lawyer guesses about the API / structures part: structs are not APIs and are much more likely to be copyrightable.  The layout of a struct is not "obvious" in the sense that there is only one way to write it given a specification.  Structs definitely are code (as are APIs once they are written in a given language).  An instantiated struct, e.g. a global, does become bytes in object code.  Linking against such an object file would probably be okay if the code was LGPL licensed, but as far as I can see, mlv.h is not LGPL.

The easiest option would be use GPLv2.  Any particular reason why you want to use MIT?

General Development / Re: Translating Menus
« on: September 29, 2021, 09:00:12 PM »
Also see these tools I made for converting BDF format fonts to Canon format:
There are several freely available BDF fonts with permissive licenses (some including extended Roman and/or non-Roman character sets).

Petabyte, it looks like your mcufont repo has a license violation re the Bitstream fonts as you modify their files and the license says you can't do that if you keep the font names.  Easy enough to fix, change the font names.

Okay, hdparm branch, that's on heptapod too.  Yes, the hardcoded 3.19 is likely breaking your build, it points to a location in /home.  That's very hackish.  It suggests whoever was working on this had linux source directly there (and that this code is not at all ready for release).

The clean solution is probably to work out why there's a dependency on types.h and remove it.  Likely not too hard.

That Makefile is very different to mine.  What repo & branch are you using?

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