EOS M3 porting [M3] [EOS_M3]

srsa_4c

Can someone please check whether the set_zoom() script command crashes the camera?

Ant

srsa_4c
Can someone please check whether the set_zoom() script command crashes the camera?

Revision 5144, lua set_zoom(1) - crashes in movie mode only.

@srsa_4c
If you will commit changes, please modify CAM_DATE_FOLDER_NAMING to 0x80.

srsa_4c

Ant

srsa_4c
Can someone please check whether the set_zoom() script command crashes the camera?

Revision 5144, lua set_zoom(1) - crashes in movie mode only.

@srsa_4c
If you will commit changes, please modify CAM_DATE_FOLDER_NAMING to 0x80.

Committed the fixes in r5148.
Apparently, Canon doesn't plan to release a lens with built-in zoom motor.

Ant

srsa_4cApparently, Canon doesn't plan to release a lens with built-in zoom motor.

There is only one device.
https://shop.usa.canon.com/shop/en/catalog/power-zoom-adapter-pz-e1

srsa_4c

Ant
There is only one device.
https://shop.usa.canon.com/shop/en/catalog/power-zoom-adapter-pz-e1

Yeah, I remembered that. But I wasn't aware that it can be controlled by camera

Remote control function is available using smartphones and computers when used with an EOS 80D camera and Canon Camera Connect software.

But that's only one camera and one lens, like it wasn't meant seriously.

Ant

Agree.
At the same time we can try to implement focus related functions.
But AFAIK the problem is that focus pulse counter becomes 0 after auto focusing.

srsa_4c

Ant
At the same time we can try to implement focus related functions.
But AFAIK the problem is that focus pulse counter becomes 0 after auto focusing.

The bigger problem is that we'd need something that works with subject distance. I haven't yet tried to go after that lens info function and the source of those subject distance values in the quoted post.

Ant

srsa_4cthe source of those subject distance values in the quoted post

On EOS M3 these values can be taken directly from the lens using EFLensCom.DistanceInfo (0xFC43DF5E), or from structure in RAM at address 0x00244918.
The second way IMHO is better becuse it does not waste Camera<>Lense traffic.

srsa_4c

Ant
On EOS M3 these values can be taken directly from the lens using EFLensCom.DistanceInfo (0xFC43DF5E), or from structure in RAM at address 0x00244918.

Do you happen to know where those values are populated? 0x244918 is inside a huge structure and is not referenced directly (the firmware's addressing is very hard to follow, lots of base + offset variations).
Even with this, we only have read only access to distance data - still no way to adapt to the current CHDK interface.

aolley

Hi there
Can anyone confirm that GRIDS works with the current build for the M3? Particularly in conjunction with an evf? This is the only feature I'm really interested in and am considering buying the camera for this reason. I have an M with ML but I would really like to use an EVF with a custom crop overlay
thanks

srsa_4c

aolley
Can anyone confirm that GRIDS works with the current build for the M3? Particularly in conjunction with an evf?

As far as I know, the m3 port has no support for the evf. That means, when evf or hdmi is in use, the CHDK overlay becomes unusable/unreadable.
Even if evf was supported, CHDK grids need to be adapted to the resolution of the output device, which work has obviously not been done either (the EVF has higher res than the LCD).

aolley

Thanks for the clarification

c_joerg

Ant
I don't have EVF-DC1 and this feature was not tested,

Yes I know thatâ€¦ I have one now 😉 â€¦

srsa_4c
Even if evf was supported,

I did not expect the EVF to be supported by CHDK. However, CHDK seems to disturb the EVF. After loading, the top lines and one line in the middle are destroyed. If I open a CHDK menu, then almost half of the EVF is disturbed. Presumably some buffer will somehow be overwrittenâ€¦

Ant

@c_joerg

You can try modify display resolutions for EVF inside this function
Current display type can be found here

c_joerg

I think I got it so far...

Ant
Current display type can be found here

I first had to find the display type. Of course, it is difficult to find with debug if the display does not work. Well, I have to write a script which logs this value all the time.

Ant
You can try modify display resolutions for EVF inside this function

Then I have to put the right resolution (XGA, 1024x76😎 in update_screen_dimensions
After that I have to rebuild CHDK. I've never done that before, but it's time do itâ€¦

Ant

c_joergOf course, it is difficult to find with debug if the display does not work.

Use CHDKPTP.

Another way is creating RAM dump with delay to attach EVF. This also could be helpfull to find addresses and resolution of display buffers...

reyalp

FWIW, if you use

set gui_verbose=2

chdkptp will report the various buffer dimensions used in the console when they change.

c_joerg

reyalp
FWIW, if you use
[code]set gui_verbose=2[/code]
chdkptp will report the various buffer dimensions used in the console when they change.

Thanks for the hint.

For the size I get the following information.

vp.buffer_width:736->736
vp.visible_width:720->1024
vp.visible_height:480->684

However, I also get some errors. I attached the list.

Is â€œfb_typeâ€ the â€œdisplay typeâ€ which changes from 2 to 4?

gui_verbose_M3.txt

62.23KB

srsa_4c

c_joerg
Is â€œfb_typeâ€ the â€œdisplay typeâ€ which changes from 2 to 4?

I don't think so, but reyalp can correct me if I'm wrong.
You can get the displaytype by executing the following in chdkptp.
firmware 101a:

=return peek(0x9974)

firmware 120f:

=return peek(0x9990)

In other words, you peek the displaytype variable's address that you can find in stubs_min.S.

Can you get the displaytype in following cases (you can try rec & play mode, but they might be the same):
- LCD mode
- EVF mode
- HDMI mode

The framebuffer dimensions should be in sub_FC177FCA for 101a, but I see 640px widths there for types 0,3,4,5, which I find confusing.

reyalp

c_joerg
However, I also get some errors. I attached the list.

vp.buffer_width:736->736
vp.visible_width:720->1024

So the visible width updates correctly to 1024 (based on _GetVRAMHPixelsSize), but the buffer width (which would be set in update_screen_dimensions) does not.

Is â€œfb_typeâ€ the â€œdisplay typeâ€ which changes from 2 to 4?

No, that just indicates the format of the buffer. The vp is viewfinder, bm is bitmap / ui, bmo is the opacity channel for the bitmap. The types of a given buffer don't change at runtime.

« Previous Page Next Page »