EOS M3 porting - page 40 - DryOS Development - CHDK Forum
supplierdeeply

EOS M3 porting

  • 613 Replies
  • 203435 Views
*

Offline Ant

  • ****
  • 431
Re: EOS M3 porting
« Reply #390 on: 05 / July / 2017, 16:05:42 »
Advertisements
You could try putting in a short delay in set_tv96 right before it sets the tv propcases to see if that makes a difference.
I don't think it's good idea to make platform specific changes in CHDK core.
Maybe it's better to put a delay in the script?

*

Offline Ant

  • ****
  • 431
Re: EOS M3 porting
« Reply #391 on: 05 / July / 2017, 16:30:18 »
Latest CHDK builds r4849 for EOS M3 fw 101a & 120f.
But it's better to distribute them from the autobuild server...

Edit:
r4849M - UHS enabled for fw 101a too
« Last Edit: 07 / July / 2017, 12:27:50 by Ant »

*

Offline lapser

  • *****
  • 1093
Re: EOS M3 porting
« Reply #392 on: 05 / July / 2017, 17:33:13 »
You could try putting in a short delay in set_tv96 right before it sets the tv propcases to see if that makes a difference.
I don't think it's good idea to make platform specific changes in CHDK core.
Maybe it's better to put a delay in the script?
I was suggesting a way to test to see what the problem is. You can't do the delay in the script, it has to be done in set_tv96() to get the timing right. If the test works, there would have to be changes made to set_tv96() that work across platforms.
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

*

Offline reyalp

  • ******
  • 12111
Re: EOS M3 porting
« Reply #393 on: 06 / July / 2017, 23:01:28 »
Quote
The developers of these ports have not added them or requested they be added.
Feel free to add them. :D
Of course I'm free to add it, the question is whether it's ready ;)

Are you comfortable if people use it without visiting the development thread?

Does the notes.txt reflect the actual state of the port? What functionality is impacted by the
presence of a removable lens?

Does it need the UHS fix from https://chdk.setepontos.com/index.php?topic=13089.msg132583#msg132583 ?

In general, I'd appreciated it if you could do a bit of cleanup before adding it to the autobuild. Disable (#ifdef or #if 0) debugging code, fix the modemap, remove the extraneous GPS stuff in lib.c, try to comment which things are actually still to be done, go though platform_camera.h and make sure the values make sense, or comment the ones that are unknown.

I understand this is a bit boring, but it's a lot easier for someone who has the camera to do.
Don't forget what the H stands for.


*

Offline Ant

  • ****
  • 431
Re: EOS M3 porting
« Reply #394 on: 07 / July / 2017, 02:52:23 »
Of course I'm free to add it, the question is whether it's ready ;)
It's ready to be used to generate working binary(lacking some functionality - nobody is perfect, even Canon).

Quote
Are you comfortable if people use it without visiting the development thread?
Why should I worry?


Quote
Does it need the UHS fix from https://chdk.setepontos.com/index.php?topic=13089.msg132583#msg132583 ?
For 120f - no need
For 101a this line should be added.

Quote
In general, I'd appreciated it if you could do a bit of cleanup before adding it to the autobuild.
I think it's necessary for developers, not for consumers.
Are you sure all other D6 ports fully comply to your requirements?
« Last Edit: 07 / July / 2017, 03:04:35 by Ant »

*

Offline reyalp

  • ******
  • 12111
Re: EOS M3 porting
« Reply #395 on: 08 / July / 2017, 00:15:32 »
Quote
Are you comfortable if people use it without visiting the development thread?
Why should I worry?
IMO, people who download from the downloads page or through a tool like stick should get something that mostly works, or at least has any major broken / missing parts documented.

I'm asking you because I can't judge how functional a port is from the source, and yours is the first to support interchangeable lenses.
Quote
For 101a this line should be added.
Thanks. Added.

Quote
Quote
In general, I'd appreciated it if you could do a bit of cleanup before adding it to the autobuild.
I think it's necessary for developers, not for consumers.
I end up supporting pretty much every port in the autobuild. The more time I spend wading through irrelevant, broken copy / paste code or random debugging leftovers, the harder it is for me to do that...

Quote
Are you sure all other D6 ports fully comply to your requirements?
I certainly made an effort to clean up the g7x port and document what does and does not work before adding it to the autobuild.
Don't forget what the H stands for.

Re: EOS M3 porting
« Reply #396 on: 08 / July / 2017, 01:10:28 »
IMO, people who download from the downloads page or through a tool like stick should get something that mostly works, or at least has any major broken / missing parts documented.

FWIW CHIMP 0.9.4 adds the option to show the camera's notes (notes.txt in platform, camnotes.txt in build). It's checked by default (probably should be unchecked in case of an update). Therefore, if the broken/missing parts are properly documented, the user will most definitely be aware of them.
Author of CHIMP, Canon Hack Installation and Management Platform

*

Offline reyalp

  • ******
  • 12111
Re: EOS M3 porting
« Reply #397 on: 09 / July / 2017, 20:35:01 »
Here's some "blind" cleanup and notes

Cleanup
* put capt_seq and filewrite code under #ifdefs. I like to have these off in autobuilds, because the log strings could make it more obvious CHDK was used (though a romlog would probably be a pretty obvious clue anyway).
* lib.c remove hook_raw_size (not used in modern CHDK) and gps related functions
* remove bin_comp_fix.h. Values generated by the normal process should be OK

I can check this in if you can confirm it still works correctly.


Other notes below. I'm *not* saying you need to fix / address all of these, or criticizing your work. It's just a list of what I noticed as I tried to review the port.

* It's a good idea to try to track down which settings the raw buffer address is actually valid for. People will probably mostly use native raw, but raw hooks still depend on a valid buffer being available. Users might also be tempted to use DNG in when Canon settings do not allow Canon raw, and using DNG with and incorrect address can result in massive memory corruption. The platform_camera.h CAM_DISABLE_RAW_IN_ defines should reflect the actual modes on the camera, adding to the core if needed.
* CAM_DNG_LENS_INFO is defined in platform_camera.h, but obviously correct values depend on the lens. The implications of this should be looked into.
* CAM_SD_OVER_IN_AF and MF are defined. Do subject distance overrides actually work on this camera?
* CAMERA_MIN_DIST / CAMERA_MAX_DIS are defined. Are they really correct? Are they lens dependent ?
* If the Canon firmware does DFS, dark frame control can probably be done like g7x, (https://chdk.setepontos.com/index.php?topic=12714.msg133735#msg133735)
* In lib.c, vid_get_viewport_fb_d is set to a constant address. This is almost certainly incorrect some of the time. This is the viewport buffer in playback mode, so would only affect PTP live view or zebra/histogram/edge in playback.
* The modemap entries listed as "modemap entry not found in firmware" should probably be removed (unless finsig_thumb2 isn't identifying the modemap correctly). The ones listed as "In firmware but not in current modemap" should be identified and added where possible (except for C modes, which CHDK currently doesn't support). The values should also be checked (e.g. M really is 32770). This mainly affects scripts that attempt to get or set the current shooting mode, and PTP control.
* shooting.c Av table is obviously not valid for all lenses. Implications should investigated (probably minor, but would allow the non _direct version to try to set out-of-range values.)
* Do Av overrides work at all?
* Zoom related limited should be noted in notes.txt (I assume CHDK can't control zoom, there are no real zoom_in/zoom_out keys to click but other keys are mapped to them for script)
Don't forget what the H stands for.


*

Offline Ant

  • ****
  • 431
Re: EOS M3 porting
« Reply #398 on: 10 / July / 2017, 13:33:05 »
Users might also be tempted to use DNG in when Canon settings do not allow Canon raw, and using DNG with and incorrect address can result in massive memory corruption. The platform_camera.h CAM_DISABLE_RAW_IN_ defines should reflect the actual modes on the camera, adding to the core if needed.
There are many modes where DNG shooting doesn't work / buffers have defferent addresses. IMHO it's better to use the "white list" (PTAM modes).

Quote
* CAM_DNG_LENS_INFO is defined in platform_camera.h, but obviously correct values depend on the lens. The implications of this should be looked into.
* CAM_SD_OVER_IN_AF and MF are defined. Do subject distance overrides actually work on this camera?
* CAMERA_MIN_DIST / CAMERA_MAX_DIS are defined. Are they really correct? Are they lens dependent ?
Focus control has not yet been implemented. Only the focal length displaying works.

Quote
* If the Canon firmware does DFS, dark frame control can probably be done like g7x, (https://chdk.setepontos.com/index.php?topic=12714.msg133735#msg133735)
I will look.

Quote
This is the viewport buffer in playback mode, so would only affect PTP live view or zebra/histogram/edge in playback.
IIRC there were problems in playback mode. Have you found a solution?

Quote
* shooting.c Av table is obviously not valid for all lenses. Implications should investigated (probably minor, but would allow the non _direct version to try to set out-of-range values.)
I think the lens should reject wrong values. I'll check.

Quote
* Do Av overrides work at all?
It works, but I didn't meter how precise it work. At least I can see the difference between F8 and F5.

Quote
* Zoom related limited should be noted in notes.txt (I assume CHDK can't control zoom, there are no real zoom_in/zoom_out keys to click but other keys are mapped to them for script)
Most EF/EF-S/EF-M lenses don't have motorised zoom function. It's obvious for their users. But zoom buttons are used in playback mode.
« Last Edit: 10 / July / 2017, 13:34:44 by Ant »

*

Offline reyalp

  • ******
  • 12111
Re: EOS M3 porting
« Reply #399 on: 10 / July / 2017, 16:47:52 »
There are many modes where DNG shooting doesn't work / buffers have defferent addresses. IMHO it's better to use the "white list" (PTAM modes).
The approach I used on g7x (https://chdk.setepontos.com/index.php?topic=13095.0) covers pretty much everything except for modes that take multiple exposures. I haven't looked to see if the M3 firmware is similar.

Quote
Focus control has not yet been implemented. Only the focal length displaying works.
OK, then the CAM_SD_OVER_IN_* should all be off.
Quote
Quote
This is the viewport buffer in playback mode, so would only affect PTP live view or zebra/histogram/edge in playback.
IIRC there were problems in playback mode. Have you found a solution?
The value use on sx60 and g7x seems to work correctly. See https://chdk.setepontos.com/index.php?topic=12532.msg129914#msg129914
Don't forget what the H stands for.

 

Related Topics