Messages

[R]

R firmware 1.3: https://www.canon.co.uk/support/consumer_products/products/cameras/digital_slr/eos-r.html?type=firmware

Firmware Version 1.3.0 incorporates the following enhancement:
1. Support for the RF24-240mm F4-6.3 IS USM lens has been added.

RP firmware 1.2: https://www.canon.co.uk/support/consumer_products/products/cameras/digital_slr/eos-rp.html?type=firmware

Firmware Version 1.2.0 incorporates the following enhancement and fix:
1. Support for the RF24-240mm F4-6.3 IS USM lens has been added.
2. Corrects a phenomenon in which the top of some captured images may be dark during high-speed sync shooting with an external flash.

No mentions about fixes for recent vulnerabilities.

Then it worked fine.  In theory it has preserved the hg hashes as I chose the option to "Annotate commits with the hg hash as git notes in the hg namespace".  Haven't tested thoroughly, but you can get what look like useful mappings of Git commits to hg hashes via: git notes --ref hg list

Yup, that should work. We are migrating SVN workflow to Git and protocol v1 gets overwhelmed if you have too many tags in your repo (and we are creating a ton of them every day). Git notes was found to be one of better solutions for this problem - you can search them easily.

Wonder what will be next: 100D?

Great work!

I asked Eyal Itkin directly and from what he told me - they tested this only on 80D. List of affected cameras was prepared by Canon themselves.

EOS R firmware version 1.3.0 and earlier

Hmm, I'm sure the latest public one is 1.2.0

Anyway, seems like a possible entrypoint to enable bootflag on R.

I thought about PR into unified which this is based on
Obviously taking this as a new branch in ML repo is different story - and may encourage others to give it a try.

I really need to find some time and dig for stubs on R to try this. I hope for next month - depends mostly on how long will take me to migrate all stuff from server running in my closet to full-blown rack setup in my parents house ("just IT things") 
You know that you work on too many items at once when you have multiple kanban boards just for your own projects...
/ot

Do you have a pull request available? It might help others to chime in

https://bitbucket.org/stephen-e/ml_200d/
I don't think that this will be ready for PR anytime soon 

I fixed it! (well, almost)

Problem was with aperture motor itself. After disassembling it (it's held to aperture assembly by few plastic tabs and 4 solder joints to ribbon), using some wd40 for cleaning it up (just two electromagnets and pivot that should not touch magnets) aperture works OK.
Camera will still drop Err01 when I'll do some shots on f/16-f/20, but that seems to be a bit different problem. Seems that it's not aware of real aperture position since it has only one sensor. And it's done by simple wire spring (not-)touching metal element - contact is broken by pin moving with aperture itself. I noticed it was barely touching when fully open, so I slightly bent it and that made it working more reliably.

My theory that err01 is now caused by this sensor is backed up by behaviour - I can play how long I want in movie mode, it won't fail. It will fail in photo mode always after photo is successfully made with proper exposition - when it opens aperture back and maybe overshot now? After i bent spring, it may lose contact for fraction of second when going back from fully closed...

Anyway, it works even on R high-fps mode when closed at least to F/8 without errors, so it's usable again 

Thats why I asked my question - in Polish (I understand German enough for his post)
For 'when' question no wonder answer was rude. For donations, it was short but not rude.
Maybe it's better to remove those posts asking for dates, instead of replying like this every time...

Warum so eine unfreundliche Antwort auf eine gute Frage?

Która odpowiedź jest niegrzeczna?*

English, please. 

Sorry, had to.

Now that's what i call progress!
Need to find some time and finally dig into your repository.

Inb4 "so when download be available?" -> answer from a few posts ago apply exactly the same now.

durability working in overclocking

Overclocking and durability, choose one. It's all about silicon lottery. Info that somebody's card survives OC means nothing about other cards even from the same batch.

kitor: I don't think bmp_putpixel_fast() is called with rgb values at all.  Look at the values when it's called, and the constants in bmp.h, eg, COLOR_WHITE is 1, COLOR_BLACK is 2.  Indexed colour maybe.  I need to understand this better before I can change it.  Probably won't have much time to work on it before the weekend.

You are right! I looked at uint_8t, saw color definitions and just assumed it without looking at the numbers. Lesson learned once again: don't assume things 
https://magiclantern.fandom.com/wiki/VRAM/BMP
https://chdk.fandom.com/wiki/Frame_buffers -> "Bitmap (or Overlay)"
https://chdk.fandom.com/wiki/Palette
Indeed that's an indexed palette, i guess that it was more consistent between EOS cameras than on PowerShot models, but this apply:

Code Select Expand

#define COLOR_TRANSPARENT_GRAY  0x14 // not portable, old cameras show it as magenta

Since CHDK is running on D6+ cameras, I checked their code (on dev trunk) and while their functions have a bit different definitions, core/gui_draw.c seems to have all the magic implemented that needs to be ported here.

I see some discussion about YUV stuff on chdk forum -> https://chdk.setepontos.com/index.php?topic=11316.120

As for "simply replacing" - from what I understand now, YUV buffers have also alpha channel, so replacing rgb values with yuv ones will produce werid results (mentioned in chdk thread too). And Canon seemed to change this twice - once to UYVY + separate opacity data that's in 200D (according to comments in minimal.c - and by "adapted from names_are_hard" i believe you are aware of that ) and then to UYVYAA (5D4, M50, R...)

For now I would just replace bmp_putpixel_fast with implementation based on CONFIG_DIGIC_678 part of disp_set_pixel in digic6-dumper/minimal/hello-world/minimal.c, completly ignoring bvram and converting 8 bit input into 32 by some bitwise operations (?, i was never good at optimizing low-level stuff) since now it's hardcoded to white. This surely will be order of magnitude slower, but if that takes us into ML menu, i guess that's good idea to fix/optimize it after we know that we can do GUI stuff.

As for

disp_set_pixel() also wants fixing in unified, which isn't as simple as I expected, a bunch of symbols are in different places in unified vs digic6-dumper.

I thought that this is used only from BL context, so not required at this stage:

Code Select Expand

grep -irw disp_set_pixel ./
./src/font_direct.c:    disp_set_pixel(x, y, c);
./src/disp_direct.c:void disp_set_pixel(uint32_t x, uint32_t y, uint32_t color)
./src/minimal.c:void disp_set_pixel(int x, int y, int c)
./src/disp_direct.h:void disp_set_pixel(uint32_t x, uint32_t y, uint32_t color);


Won't bmp_putpixel_fast from bmp.h be a problem here? It's used by font_draw_char from frb_font.c:

Code Select Expand


inline void bmp_putpixel_fast(uint8_t * const bvram, int x, int y, uint8_t color)
{
    /* vxvorks skipped */
    bvram[x + y * BMPPITCH] = color;
    /* 500d skipped ;) */
}

It's definitely not YUV-aware.

What about replacing it with code based on disp_set_pixel from minimal.c in digic6-dumper?

Try to learn back-button focus: reconfigure your half-shutter to AE lock, use AF-ON with your thumb for AF.
Takes a day to get used off it, but now you basically can keep your camera in AI-Servo, and you will never come back

You want to have your half-shutter to be "AF Start & AE lock on AF success". This indeed can't be achieved on stock FW, not sure if ML can help (is ML able to get "focus" event).

@kitor How did you measure the pitch of the FPC connector with that small size?

Caliper 

P.S there is a very slim chance of me opening up the camera and probing points as my parents will most likely evaporate me from existence if they found out.

And I disassembled mine. Still over a year to end loan payments, but that's the things you do for Science!

Very interesting, mine isn't FPC.  Jack's has a K2 label, I have K1 - and inside 3 exposed pads.  Serial port without ground?

Took me a moment to realize "K1" and "K2" is molded into case. I don't believe it's related to what's inside. More likely different factory code or something.

Side note: While RP on promo video had both debug connectors soldered (like my retail R does, 2nd we guess to be jtag), on photos from retail ones this 2nd connector is missing (pads only).
If those 3 pins are serial, then my bet is rx/tx/gnd, but IIRC all known cameras exposes both CPU and MPU serial ports, so this would be werid.

Since quality of picture is as visible, I see like three pads with solder on them just above those three, and something possibly hidden under sticker... like if connector just isn't soldered in.
That would fit as connector is 8 pin, soldered 4 pins on each side of connector.
I can't find any high res photo of the board to confirm those suspicions. Look at 2nd photo here: Aliexpress - that's best I found.

So at least location is right. As for this FPC pitch - I doubt you will find one, I measured it to be probably 0.4mm (maybe 0,35mm - hard to measure without desoldering connector), found just a single china source for matching parts... 
I don't think they are using different pinouts, as connector is already exotic (it's impossible to use standard 0.5mm cable as it will short pins to ground). But if you find anything (or want to disassemble camera - on R there are testpads near connector that I used for all of my work), please update thread I linked before with your findings 

@names_are_hard - debug connector is very useful. In R stubs you can find one for uart_printf, that was the only way I was able to debug R before I found out my RAM dump was wrong and I had 1-byte offset framebuffer location

By looking at the board photo from Aliexpress, it's the same style connector as on EOS R / RP, located under thumb rubber, near USB connector.
Just educated guess.

As connector is visually the same, pinout for R is here:
https://www.magiclantern.fm/forum/index.php?topic=7531.msg212071#msg212071

If that checks out - FPC that goes into it is less than usuall 0.5mm pitch.

Not sure if this should go here or into general chat, since it's not camera and ML related.

Recently I got old EF 20-35 3.5-4.5 USM lens. Pretty good external and internal condition, focuses fast, shoots OK, but...
Shoots OK only wide open. Trying to shoot with lower aperture ends in err01 both on R and 5d3.

After some guessing I noticed that lens reacts randomly to aperture changes - this is best noticeable in movie mode where aperture should be kept at selected step all the time.
General rule is that closing from 3.5 in direction of f/29, step after step - it will close two steps, then open by one, then close by a few, then open a few and so on. When camera says it should be f/29, lens is really at about f/16 maybe. Behavior is inconsistent - most of the time it will change aperture in proper direction, sometimes it won't react at all and sometimes goes into opposite than requested.

I disassembled it twice - checked aperture ribbon - seems ok (both visually and using multimetr), disassembled even aperture itself - i can move it in both directions as freely as stepper motor allows me to do.
With each aperture "step" motor is making noises.

I wonder if the problem is in lens controller, ribbon or motor itself. Will use it wide open (as there are no hopes for parts for ~$150 lens, unless someone sells me dropped one with broken glass), but maybe someone had similar problem with any of Canon lenses?

I don't see any info what card are you using, only this:

Card Warm Up: 128 MB (I have 128GB CF Card)

Have you tried with different cards?

For RWD 16:9 videos I always used this CSS, don't remember original source now:

Code Select Expand

.embed-container {
    position:       relative;
    padding-bottom: 56.25%;   /* 16/9 ratio */
/*  padding-top:    30px; /* IE6 workaround*/
    height:         0;
    overflow:       hidden;
    margin-bottom:  10px;
    border-radius:  2px;
    z-index:        1;
    }

.embed-container iframe,
.embed-container object,
.embed-container embed,
.embed-container div.embed {
    position:       absolute;
    top:            0;
    left:           0;
    width:          100%;
    height:         100%;
    }

Of course whatever is inserted inside has to have no width/height set. This worked at least for YT, FB and I think Vimeo videos.
And you may add max-width to .embed-container since it will fill parent (which was expected in my case)

https://www.magiclantern.fm/forum/index.php?topic=12523.0

Hello,
is there somebody, who is still working on ML for Canon EOS R? 

Refer to this. No posts = no news.

f. e. Intervalometer, Motion detection,

So we have something in common (had to bring notebook with me last time I suddenly needed intervalometer). However I risked a lot to my camera (as seen in this thread) to at least try to make it happen.