Author Topic: Assign lens focal length and name for non cpu lenses (Read 164965 times)

dfort · « **Reply #375 on:** August 12, 2018, 02:13:43 AM »

Ok--you can do the pull request on manual_lens_info but the development branch DuJour is crop_rec_4k_mlv_snd. That's where g3gg0 did the latest fixes on mlv_dump.

The crop_rec_4k branch has some recent commits that aren't working yet--EOSM and 700D enabled FRAME_SHUTTER_BLANKING_READ/WRITE. Besides, the goal is to eliminate mlv_rec with mlv_lite and the crop_rec_4k_mlv_snd branch looks like it is ready for that step.

My crop_rec_4k_ELNS branch has the crop_rec_4k_mlv_snd merged in and seems to be working nicely so go ahead and grab that branch from my repository when you do the pull request on the crop_rec_4k_mlv_snd branch.

You can try merging manual_lens_info into crop_rec_4k_mlv_snd and resolve the conflicts using my crop_rec_4k_ELNS branch but that will create a huge changeset. Better break it down into manageable hunks.

Oh--and don't worry about who gets credit for which line of code. You did all the heavy lifting on this. I was just the enabler--you know, the good definition of enabler.

aprofiti · « **Reply #376 on:** August 13, 2018, 02:03:02 PM »

Found a bug after taking a silent picture in a commit from lua_fix.

Doens't happens with mlv_rec, mlv_lite and if I comment "force_liveview()" line.
Maybe it get queued?

aprofiti · « **Reply #377 on:** August 14, 2018, 02:56:33 AM »

I'm trying to merge manual_lens_info to crop_rec_4k_mlv_snd but I'm a bit confused on which changes use to solve conflicts from commits made in lua_fix and the experimental stuffs from the other branch.

Is it possible to merge lua_fix into crop_rec_4k_mlv_snd? This should make managing conflicts from manual_lens_info much easier, and should also make changeset much lighter... Also should leaves diffs from manual_lens_info code when pushing the PR, making room for commits names suggested by g3gg0

dfort · « **Reply #378 on:** August 14, 2018, 07:02:59 AM »

Quote from: aprofiti on August 14, 2018, 02:56:33 AM

Is it possible to merge lua_fix into crop_rec_4k_mlv_snd?

Done.

Merged cleanly and tested out fine so I went ahead and committed it. The lua_fix branch has been merged into crop_rec_4k a few time and then crop_rec_4k merged into crop_rec_4k_mlv_snd but it looks like these branches are a bit behind the latest lua_fix changes. Since there is some work in progress on the crop_rec_4k branch that affects the EOSM and 700D I didn't want to mess around with merging lua_fix into it.

aprofiti · « **Reply #379 on:** August 14, 2018, 11:16:41 AM »

Quote from: dfort on August 14, 2018, 07:02:59 AM

Merged cleanly and tested out fine so I went ahead and committed it. The lua_fix branch has been merged into crop_rec_4k a few time and then crop_rec_4k merged into crop_rec_4k_mlv_snd but it looks like these branches are a bit behind the latest lua_fix changes. Since there is some work in progress on the crop_rec_4k branch that affects the EOSM and 700D I didn't want to mess around with merging lua_fix into it.

Thank you dfort, It's looking much better and now i have only to figure out a conflict with raw.c (It touching 70D) apart the ones on the modules (easy to solve). Will look into it later or tomorrow.

Are these the commits name to follow?

Code: [Select]

“advanced lens information in ML core”
“added LUA interface and functions to set manual lens data”
“mlv_rec: add ELNS support”
“mlv_lite: add ELNS support”
“silent: handle advanced lens info”

dfort · « **Reply #380 on:** August 15, 2018, 07:20:02 AM »

Quote from: aprofiti on August 14, 2018, 11:16:41 AM

Are these the commits name to follow?
Code: [Select]
“advanced lens information in ML core” “added LUA interface and functions to set manual lens data” “mlv_rec: add ELNS support” “mlv_lite: add ELNS support” “silent: handle advanced lens info”

That's the list g3gg0 gave us so I would say yes.

aprofiti · « **Reply #381 on:** August 15, 2018, 10:09:01 PM »

Submitted a new pull request with changes for crop_rec_4k and another one to update manual_lens_info branch (also here lua_fix can be merged into the official repo's branch, to make it easier to see what's changed).

To make the first one I started with a merge from manual_lens_info and then removed all manual_lens_info diffs (except the one not included in lua_fix like property.c, modules.c... they are in first commit) from files by reverting changes to crop_rec_4k_mlv_snd revision.
After that I started to reapply diffs to implement ELNS processing and committed into separate changesets.

Is this an acceptable way to guarantee the maintainability that @g3gg0 was looking for?

aprofiti · « **Reply #382 on:** September 15, 2018, 05:07:52 PM »

Having troubles again with selftest module.

With the fix for fast_malloc return type it can be compiled and run on camera, but the test for "Small-block malloc test" will not works (ui freezes and ERR99 in viewfinder) when I merge lua_fix into it...
Tried also the inverse (manual_lens_info -> lua_fix) but same problem occurs, only works as current state of manual_lens_info branch.

@a1ex Can you merge lua_fix into manual_lens_info an solve conflicts for me?

Also I have a doubt about the script:
It set lens_info.exists to true to enable all the extra info (lens info menu, aperture/focal length in lv etc...) to works with a manual lens.

Noticed that this commit by dmilligan where it was originally adding a field is_Chipped, now replaced with d0e55b3 (use field lens_info.exists).
Here setting field exists will have as consequence some menu text to be displayed, enable dot_tune for non chipped adapter and the one is questioning me more: ETTR exposure bug with manual_lens

Is better to add another field like is_mManual or is_Chipped to be set by lens.lua and replace adapt those checks?

Lars Steenhoff · « **Reply #383 on:** September 22, 2018, 06:56:14 PM »

Wish I could help

aprofiti · « **Reply #384 on:** September 24, 2018, 02:21:47 PM »

Quote from: Lars Steenhoff on September 22, 2018, 06:56:14 PM

Wish I could help

Having additional feedback is welcome.

You can have a look about this list:
1. Overall camera stability
2. Raw recording and silent pictures stability, especially mlv_rec which was the most problematic to make it works
3. General feedback about the script and metadata correctness
4. Eventually other bugs that can pop out

Those should be checked on both PR (take the branches from my repo); if you are a main crop_rec_4k branch user, having that on a daily usage is a nice addition to extensively testing it.

Waiting for you feedback. After all, you starter the thread

dfort · « **Reply #385 on:** September 24, 2018, 09:24:58 PM »

Quote from: aprofiti on September 15, 2018, 05:07:52 PM

Can you merge lua_fix into manual_lens_info an solve conflicts for me?

I looked into this and the merge conflicts shouldn't be difficult to resolve. I resolved it by taking the mem.c changes from the lua_fix branch because it has the newer memory backend updates. However, a problem after merging is that the selftest module will no longer compile. I believe that the latest changes to that module was done in the lua_fix branch and simply copying selftest.c from lua_fix it compiles and seems to work properly.

Lars Steenhoff · « **Reply #386 on:** September 26, 2018, 10:08:43 PM »

@aprofiti.

with one is the best for testing
Latest Build (2018-09-13 23:06)
https://builds.magiclantern.fm/experiments.html
this one form experiments or one from your branch?

aprofiti · « **Reply #387 on:** September 27, 2018, 01:33:37 AM »

Quote from: Lars Steenhoff on September 26, 2018, 10:08:43 PM

this one form experiments or one from your branch?

Take the ones from my branch (manual_lens_info and crop_rec_4k_mlv_snd_elns).

The build from experimental page is an older one, not with the "dynamic" field length, it only include fix for compilation of selftest module but can also be less stable due to missing merge of latest lua_fix used to avoid camera crash when recording raw.

Quote from: dfort on September 24, 2018, 09:24:58 PM

I looked into this and the merge conflicts shouldn't be difficult to resolve. I resolved it by taking the mem.c changes from the lua_fix branch because it has the newer memory backend updates. However, a problem after merging is that the selftest module will no longer compile. I believe that the latest changes to that module was done in the lua_fix branch and simply copying selftest.c from lua_fix it compiles and seems to work properly.

yes, they aren't difficult to resolve, just include the changes regarding allocator to fix conflicts, but there is something which will mess selftest's module functionality.

Just taking selftest from lua_fix will be missing "Small-block malloc" test which is failing after merging; same thing if just copying mem.c (some improvement in memory management was done for manual lens); maybe there are some changes in mem.c from lua_fix which will interfere with the version in manual_lens_info

aprofiti · « **Reply #388 on:** September 29, 2018, 02:38:27 AM »

I'm trying to see where it fails using Qemu.

First run saved a couple of log in CF and "Small-malloc test" appears prints debug info in console.
Observed it was allocating 1600 block (which 1000 of these should be from fast_malloc).

Here is the crash log of second run:

Code: [Select]

ASSERT: pvAddr
at Memory\Memory.c:170, RscMgr:ff867b7c
lv:0 mode:0

RscMgr stack: 13ed20 [13ef98-13df98]
0xUNKNOWN  @ ff86f9b0:13ef90
0xUNKNOWN  @ ff99058c:13ef68
0xFF98FFE8 @ ff82aa6c:13ef40
0xUNKNOWN  @ ff990018:13ef30
0xUNKNOWN  @ ff9900a0:13ef10
0xFF8AD684 @ ff8ae2a8:13eef8
0xFF8AA0D4 @ ff8ad73c:13eec8
0xFF869068 @ ff8aa4c0:13ee58
0xFF868868 @ ff8690e4:13ee40
0xFF86874C @ ff86890c:13ee28
0xFF86AFB0 @ ff868788:13ee10
0xFF867B54 @ ff86afc8:13ed60
0xFF814AC0 @ ff867b78:13ed58
0x0004B378 @ 4b84c:13ed20

Magic Lantern version : Nightly.2018Sep29.50D109
Mercurial changeset   : cc361edea9e6+0040e6ccea8d+ (manual_lens_info)
Built on 2018-09-29 00:21:17 UTC by alex@MacBook-Pro-di-Alessandro-8.local.
Free Memory  : 64K + 56K

Qemu console of second run:

Code: [Select]

ASSERT : Memory\Memory.c, Task = RscMgr, Line 170

 AllocateMemory 40
 TASK:[RscMgr]
  20:0x8000
  19:0x8000
  18:0x4
  17:0xff86afc4
  16:0x8b2900
  15:0x28
  14:0x8000
  13:0x63eaac
  12:0x19980218
  11:0x13ed60
  10:0x13eddc
   9:0x8000
   8:0xff816904
   7:0xac0078
   6:0
   5:0x63eaac
   4:0x8000
   3:0x8000
   2:0xff98c694
   1:0x387a4  1290: 12935.424 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = RscMgr
  1291: 12935.424 [STARTUP] ERROR ASSERT : Line 170
  1292: 12935.424 [STARTUP] ERROR ASSERT : pvAddr
  1293: 12937.216 [STARTUP] startupErrorRequestChangeCBR (0x1d)
  1294: 12937.216 [STARTUP] startupErrorRequestChangeCBR : ErrorSend (101, ABORT)
[MPU] Received: 08 06 03 03 65 01 00 00  (unknown - unnamed)
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 546
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 546
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 546
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
  1295: 12959.232 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1296: 12959.232 [STARTUP] ERROR ASSERT : Line 170
  1297: 12959.232 [STARTUP] ERROR ASSERT : pvAddr
  1298: 12959.232 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1299: 12959.488 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1300: 12959.488 [STARTUP] ERROR ASSERT : Line 170
  1301: 12959.488 [STARTUP] ERROR ASSERT : pvAddr
  1302: 12959.488 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1303: 12960.000 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1304: 12960.000 [STARTUP] ERROR ASSERT : Line 170
  1305: 12960.000 [STARTUP] ERROR ASSERT : pvAddr
  1306: 12960.000 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1307: 12960.256 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1308: 12960.256 [STARTUP] ERROR ASSERT : Line 170
  1309: 12960.256 [STARTUP] ERROR ASSERT : pvAddr
  1310: 12960.256 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1311: 12960.512 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1312: 12960.512 [STARTUP] ERROR ASSERT : Line 170
  1313: 12960.512 [STARTUP] ERROR ASSERT : pvAddr
  1314: 12960.512 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1315: 12961.024 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1316: 12961.024 [STARTUP] ERROR ASSERT : Line 170
  1317: 12961.024 [STARTUP] ERROR ASSERT : pvAddr
  1318: 12961.024 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1319: 12961.024 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1320: 12961.024 [STARTUP] ERROR ASSERT : Line 170
  1321: 12961.024 [STARTUP] ERROR ASSERT : pvAddr
  1322: 12961.280 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1323: 12961.536 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1324: 12961.536 [STARTUP] ERROR ASSERT : Line 170
  1325: 12961.536 [STARTUP] ERROR ASSERT : pvAddr
  1326: 12961.536 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1327: 12961.792 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1328: 12961.792 [STARTUP] ERROR ASSERT : Line 170
  1329: 12961.792 [STARTUP] ERROR ASSERT : pvAddr
  1330: 12961.792 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1331: 12962.048 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1332: 12962.048 [STARTUP] ERROR ASSERT : Line 170
  1333: 12962.048 [STARTUP] ERROR ASSERT : pvAddr
  1334: 12962.048 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1335: 12962.304 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1336: 12962.304 [STARTUP] ERROR ASSERT : Line 170
  1337: 12962.304 [STARTUP] ERROR ASSERT : pvAddr
  1338: 12962.304 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1339: 12962.816 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1340: 12962.816 [STARTUP] ERROR ASSERT : Line 170
  1341: 12962.816 [STARTUP] ERROR ASSERT : pvAddr
  1342: 12962.816 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1343: 12963.072 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1344: 12963.072 [STARTUP] ERROR ASSERT : Line 170
  1345: 12963.072 [STARTUP] ERROR ASSERT : pvAddr
  1346: 12963.072 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1347: 12963.328 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1348: 12963.328 [STARTUP] ERROR ASSERT : Line 170
  1349: 12963.328 [STARTUP] ERROR ASSERT : pvAddr
  1350: 12963.328 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1351: 12963.584 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1352: 12963.584 [STARTUP] ERROR ASSERT : Line 170
  1353: 12963.584 [STARTUP] ERROR ASSERT : pvAddr
  1354: 12963.584 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1355: 12963.840 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1356: 12963.840 [STARTUP] ERROR ASSERT : Line 170
  1357: 12963.840 [STARTUP] ERROR ASSERT : pvAddr
  1358: 12963.840 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1359: 12964.352 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1360: 12964.352 [STARTUP] ERROR ASSERT : Line 170
  1361: 12964.352 [STARTUP] ERROR ASSERT : pvAddr
  1362: 12964.352 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1363: 12964.608 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1364: 12964.608 [STARTUP] ERROR ASSERT : Line 170
  1365: 12964.608 [STARTUP] ERROR ASSERT : pvAddr
  1366: 12964.608 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1367: 12965.120 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1368: 12965.120 [STARTUP] ERROR ASSERT : Line 170
  1369: 12965.120 [STARTUP] ERROR ASSERT : pvAddr
  1370: 12965.120 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1371: 12965.376 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1372: 12965.376 [STARTUP] ERROR ASSERT : Line 170
  1373: 12965.376 [STARTUP] ERROR ASSERT : pvAddr
  1374: 12965.376 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1375: 12965.632 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1376: 12965.632 [STARTUP] ERROR ASSERT : Line 170
  1377: 12965.632 [STARTUP] ERROR ASSERT : pvAddr
  1378: 12965.632 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1379: 12966.144 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1380: 12966.144 [STARTUP] ERROR ASSERT : Line 170
  1381: 12966.144 [STARTUP] ERROR ASSERT : pvAddr
  1382: 12966.144 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1383: 12966.400 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1384: 12966.400 [STARTUP] ERROR ASSERT : Line 170
  1385: 12966.400 [STARTUP] ERROR ASSERT : pvAddr
  1386: 12966.400 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1387: 12966.656 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1388: 12966.656 [STARTUP] ERROR ASSERT : Line 170
  1389: 12966.656 [STARTUP] ERROR ASSERT : pvAddr
  1390: 12966.656 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1391: 12966.912 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1392: 12966.912 [STARTUP] ERROR ASSERT : Line 170
  1393: 12966.912 [STARTUP] ERROR ASSERT : pvAddr
  1394: 12967.168 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1395: 12967.424 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1396: 12967.424 [STARTUP] ERROR ASSERT : Line 170
  1397: 12967.424 [STARTUP] ERROR ASSERT : pvAddr
  1398: 12967.424 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1399: 12967.680 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1400: 12967.680 [STARTUP] ERROR ASSERT : Line 170
  1401: 12967.680 [STARTUP] ERROR ASSERT : pvAddr
  1402: 12967.680 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1403: 12967.936 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1404: 12967.936 [STARTUP] ERROR ASSERT : Line 546
  1405: 12967.936 [STARTUP] ERROR ASSERT : 0
  1406: 12967.936 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1407: 12968.192 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1408: 12968.192 [STARTUP] ERROR ASSERT : Line 170
  1409: 12968.192 [STARTUP] ERROR ASSERT : pvAddr
  1410: 12968.192 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1411: 12968.448 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1412: 12968.448 [STARTUP] ERROR ASSERT : Line 170
  1413: 12968.448 [STARTUP] ERROR ASSERT : pvAddr
  1414: 12968.448 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1415: 12968.704 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1416: 12968.704 [STARTUP] ERROR ASSERT : Line 546
  1417: 12968.704 [STARTUP] ERROR ASSERT : 0
  1418: 12968.704 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1419: 12968.960 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1420: 12968.960 [STARTUP] ERROR ASSERT : Line 170
  1421: 12968.960 [STARTUP] ERROR ASSERT : pvAddr
  1422: 12968.960 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1423: 12969.216 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1424: 12969.216 [STARTUP] ERROR ASSERT : Line 170
  1425: 12969.216 [STARTUP] ERROR ASSERT : pvAddr
  1426: 12969.216 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1427: 12969.472 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1428: 12969.472 [STARTUP] ERROR ASSERT : Line 546
  1429: 12969.472 [STARTUP] ERROR ASSERT : 0
  1430: 12969.472 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1431: 12969.728 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1432: 12969.728 [STARTUP] ERROR ASSERT : Line 170
  1433: 12969.728 [STARTUP] ERROR ASSERT : pvAddr
  1434: 12969.728 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1435: 12969.984 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1436: 12969.984 [STARTUP] ERROR ASSERT : Line 170
  1437: 12969.984 [STARTUP] ERROR ASSERT : pvAddr
  1438: 12969.984 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
ASSERT : ShootMemory.c, Task = RscMgr, Line 1112
ASSERT : ShootMemory.c, Task = RscMgr, Line 1114
ASSERT : PackMemory\PackMem.c, Task = run_test, Line 479
ASSERT : Memory\Memory.c, Task = RscMgr, Line 170

 AllocateMemory 40
 TASK:[RscMgr]
  20:0x8000
  19:0x8000
  18:0x4
  17:0xff86afc4
  16:0x8caa88
  15:0x28
  14:0x8000
  13:0x63eaac
  12:0x19980218
  11:0x13ed60
  10:0x13eddc
   9:0x8000
   8:0xff816904
   7:0xac0078
   6:0
   5:0x63eaac
   4:0x8000
   3:0x8000
   2:0xff98c694
   1:0x30798  1439: 13002.752 [STARTUP] ERROR ASSERT : ShootMemory.c, Task = RscMgr
  1440: 13002.752 [STARTUP] ERROR ASSERT : Line 1112
  1441: 13003.008 [STARTUP] ERROR ASSERT : Error == SUCCESS
  1442: 13003.008 [STARTUP] ERROR ASSERT : ShootMemory.c, Task = RscMgr
  1443: 13003.008 [STARTUP] ERROR ASSERT : Line 1114
  1444: 13003.008 [STARTUP] ERROR ASSERT : Error == SUCCESS
  1445: 13003.008 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1446: 13003.008 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1447: 13003.264 [STARTUP] ERROR ASSERT : PackMemory\PackMem.c, Task = run_test
  1448: 13003.264 [STARTUP] ERROR ASSERT : Line 479
  1449: 13003.264 [STARTUP] ERROR ASSERT : IsChunkSignature( hChunk )
  1450: 13003.264 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1451: 13003.520 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = RscMgr
  1452: 13003.520 [STARTUP] ERROR ASSERT : Line 170
  1453: 13003.520 [STARTUP] ERROR ASSERT : pvAddr
  1454: 13004.800 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 546
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 546
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 546
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : ShootMemory.c, Task = RscMgr, Line 1112
ASSERT : ShootMemory.c, Task = RscMgr, Line 1114

Maybe there is something with the changes from lua_fix in allocator selection or dimension?

aprofiti · « **Reply #389 on:** October 18, 2018, 02:54:14 AM »

Figured out what is causing the crash when running "Small-block malloc" test.

These are the parameters of the allocators on both branch:

Code: [Select]

Values from lua_fix merge:

        //Malloc Allocator
        .preferred_free_space = 384 * 1024,
        .minimum_free_space = 256 * 1024,

        //Shoot malloc Allocator:
        .try_next_allocator = 1,

        .minimum_alloc_size = 64 * 1024,
        .minimum_free_space = 256 * 1024,

Values from manual_lens_info:

        //Malloc
        .preferred_free_space = 128 * 1024,
        .minimum_free_space = 64 * 1024,

        //Shoot Malloc
        .minimum_alloc_size = 5 * 1024,

Test will run fine in QEMU If I revert using the old parameters.

@a1ex They are from commit 0e56fe7, What parameter I have to use?

Lars Steenhoff · « **Reply #390 on:** October 19, 2018, 12:41:34 AM »

Good find!

I'm running a build without much problems for some time now, mosty 14 bit lossless with h264 proxy.

a1ex · « **Reply #391 on:** December 23, 2018, 12:07:48 PM »

Narrowed it down - the 50D and 5D2 use AllocateMemory for their RscMgr data structures; most other models use malloc. When allocating memory from shoot_malloc, I need to be sure Canon firmware is going to have enough space in both AllocateMemory and malloc pools. Otherwise, the firmware may run into a situation with plenty of memory in shoot_malloc, that cannot be allocated because the general-purpose allocators are full (so, RscMgr is unable to allocate its data structures for keeping track of shoot_malloc buffers).

Back then, I've assumed these two are just like 500D, which is from the same generation. Turns out, 500D uses malloc and doesn't crash on this test.

Fix coming soon.

aprofiti · « **Reply #392 on:** December 23, 2018, 02:18:36 PM »

Glad to hear this

Is the same also with 7D? If I remember correctly it was crashing also on this model when dfort tested it

dfort · « **Reply #393 on:** December 23, 2018, 06:33:04 PM »

Quote from: a1ex on December 23, 2018, 12:07:48 PM

Fix coming soon.

Yay!

Would love to get this feature into some of the other branches. We put a lot of work into this:

https://bitbucket.org/daniel_fort/magic-lantern/pull-requests/22/elns-for-crop_rec_4k/diff

a1ex · « **Reply #394 on:** December 23, 2018, 11:52:13 PM »

Will check, but I've got other priorities for this holiday season. After I'll finish them, with pleasure.

Meanwhile I've published an updated build that passes those memory allocation tests in QEMU. I'm not sure it's completely fixed; these property handlers in Lua (in particular, memory allocations performed by them) are pretty demanding for the backend.

Just for fun, here's the 5D2 failing the test in QEMU (memory corruption breaking Canon UI):

Lars Steenhoff · « **Reply #395 on:** December 24, 2018, 10:40:55 AM »

Happy Holiday!

aprofiti · « **Reply #396 on:** December 24, 2018, 11:12:28 AM »

Quick tested the new build:
Small-malloc test runs good, tried to run more times in a row without any problem

Api_test.lua failed at lv_test, will look again later.

Unfortunally it appears to be less stable when recording raw videos, like in previous builds without mem backend improvements for property handler...
Maybe fast_malloc is still needed?

Test I was running back to check raw rec:
Enter liveview and start a recording and then stop, if camera doesn't freezes exit liveview and repeat the same procedure (may fails when entering lives or after stopping rec); mlv_rec is usually less forgivable compared to mlv_lite.

In this build it fails on second run with mlv_rec and I got a camera freeze with mlv_lite when I was navigating ML menu in liveview mode after a recording

Lot of prop_request timeout in console and triggered an assert after selecting lens from menu:

Code: [Select]

ML ASSERT:
0
at ../../src/mem.c:799 (__mem_malloc), task PropMgr
lv:0 mode:3

PropMgr stack: 139c60 [139f70-138f70]
0x009D8CC4 @ 9e3fe0:139d10
0xUNKNOWN  @ 9d8da8:139cf0
0x0004E3FC @ 9fa3e4:139cd0
0x0004BB38 @ 4e438:139c90
0x0004B378 @ 4bb94:139c60

Magic Lantern version : manual_lens_info.2018Dec23.50D109
Mercurial changeset   : 0de7b671c52c (manual_lens_info) tip
Built on 2018-12-23 22:33:00 UTC by jenkins@nightly.
Free Memory  : 232K + 3150K

a1ex · « **Reply #397 on:** December 24, 2018, 11:59:23 AM »

OK, this assert is exactly what I was looking for. I wasn't able to trigger it in my tests on 5D2 after removing fast_malloc, but I'll try again.

zLOST · « **Reply #398 on:** January 18, 2019, 10:20:51 AM »

Hi,

For couple of evenings I'm playing with the latest nightly build on my 6D (damned i need some sleep) and noticed some issues.

Some of the recent changes in lua library had changed contents of dryos variables and the dryos.dcim_dir.path (used in get_sidecar_filename() @ xmp.lib) does not work anymore.
Being on linux and using daktable+gimp i have to use IMG_1234.[CR2|JPG].xmp name to have it recognized and used by DT, so i've modified the get_sidecar to:

Code: [Select]

function xmp.get_sidecar_filename() -- {{{
    return dryos.shooting_card:image_path(1) .. ".xmp"
end -- }}}

I made some changes in the XMP file format (to use the same as exiftool) and tried to save the xmp file line by line to lower the memory consumption..
Unfortunately now it crashes immediately after taking a picture (for a split of a second i can see an error with wiritng to the xmp file (which was working for me for a while, but apparently i broke something a bit later)) and all i end up with is a picture and an assert log

Code: [Select]

ML ASSERT:
0 
at ../../src/mem.c:799 (__mem_malloc), task PropMgr
lv:0 mode:3

PropMgr stack: 170dc0 [170f68-16ff68]
0xUNKNOWN  @ 468a88:170e70
0x00BFD44C @ bf8b8c:170e50
0x00BFCC88 @ bfd484:170e40
0x0044F5E0 @ bfcca8:170e30
0x0044C9F4 @ 44f61c:170df0
0x0044C478 @ 44ca50:170dc0

Magic Lantern version : manual_lens_info.2018Dec23.6D116
Mercurial changeset   : 0de7b671c52c (manual_lens_info) tip
Built on 2018-12-23 22:39:23 UTC by jenkins@nightly.
Free Memory  : 384K + 1935K

At the moment my xmp stuff looks like this:

Code: [Select]

xmp.header= [[<?xml version="1.0" encoding="UTF-8"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="MagicLantern">
 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about=""
    xmlns:exif="http://ns.adobe.com/exif/1.0/"
    xmlns:aux="http://ns.adobe.com/exif/1.0/aux/"
    exif:ExifVersion="0230">]]

xmp.footer      = [[  </rdf:Description>
 </rdf:RDF>     
</x:xmpmeta>
]]

xmp.property_format = [[   <%s>%s</%s>]]

-- predefined xmp properties
xmp.lens_make           = { name = "exif:LensMake",             format = "%s" }
xmp.lens_name           = { name = "exif:LensModel",            format = "%s" }
xmp.lens_serial         = { name = "exif:LensSerialNumber",     format = "%s" }
xmp.focal_length        = { name = "exif:FocalLength",          format = "%d/1"}
xmp.aperture            = { name = "exif:FNumber",              format = "%d/10" }
xmp.apertureMin         = { name = "exif:MinApertureValue",     format = "F%s" } 
xmp.apertureMax         = { name = "exif:MaxApertureValue",     format = "F%s" }

function xmp.get_sidecar_filename() -- {{{
    return dryos.shooting_card:image_path(1) .. ".xmp"
end -- }}} 

....

function xmp:write(filename) -- {{{
        local f = assert(io.open(filename or self.get_sidecar_filename(), "w+"))
        assert(f:write(self.header, "\n"))

        for k,v in pairs(self.properties) do
                if type(v) == "function" then
                        self.log:write("klic:"..k.."="..v())
                        assert(f:write(string.format(self.property_format, k, v(), k), "\n"))
                else    
                        self.log:write("klic:"..k.."="..v)
                        assert(f:write(string.format(self.property_format, k, v, k), "\n"))
                end     
        end     
        --f:write(string.format(self.template, str))
        assert(f:write(self.footer))
        assert(f:close())
end --- }}}

Btw: is there a way i could test these scripts in qemu on my own? restarting the camera, mounting the sdcard, copying scripts, unmounting sdcard, starting camera is pretty exhausting and annoying especially when all i find is yet another bug in my own code

a1ex · « **Reply #399 on:** January 18, 2019, 12:00:10 PM »

Right, I need to look into that. Maybe backing out b0a2f95 (i.e. re-applying 065ceae) could help.

QEMU... doesn't go as far as completing a CR2 photo capture, so it won't trigger an XMP. It is able to emulate a full-res silent picture, and that one might trigger the XMP (possibly after some fiddling). However, silent pictures don't share the same naming/numbering as regular photos, so XMPs are not going to match there. LiveView emulation is not exactly working either (it shows Canon's GUI elements, but that's all). I have both of these halfway (or rather, 10-20%) working, but they are not straightforward.

News:

Author Topic: Assign lens focal length and name for non cpu lenses (Read 164965 times)

dfort

dfort

dfort

dfort

dfort