changelog of trunk including comments / devtalk

nafraf

1305

Re: changelog of trunk including comments / devtalk

« Reply #230 on: 09 / August / 2015, 23:30:16 »

Advertisements

In trunk 4219, following this suggestion, I added CAM_DISABLE_RAW_IN_DIGITAL_IS to be used on cameras where raw capture does not work in Digital IS mode. It was set for a810 and ixus160_elph160.

Logged

philmoz

3107

Re: changelog of trunk including comments / devtalk

« Reply #231 on: 10 / August / 2015, 21:29:58 »

Changeset 4220 & 4221 removes the need for PAUSE_FOR_FILE_COUNTER for the G1X, IXUS310 an SX40.

I moved the raw hook call to the task_DvlpSeqTask - I think this is just before the JPEG image gets created.

Might also work for other cameras that use PAUSE_FOR_FILE_COUNTER.

Phil.

Logged

CHDK ports:
sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
g12 (1.00c, 1.00e, 1.00f & 1.00g)
sx130is (1.01d & 1.01f)
ixus310hs (1.00a & 1.01a)
sx40hs (1.00d, 1.00g & 1.00i)
g1x (1.00e, 1.00f & 1.00g)

reyalp

11923

Re: changelog of trunk including comments / devtalk

« Reply #232 on: 16 / August / 2015, 15:15:40 »

Quote from: philmoz on 10 / August / 2015, 21:29:58

Changeset 4220 & 4221 removes the need for PAUSE_FOR_FILE_COUNTER for the G1X, IXUS310 an SX40.

I moved the raw hook call to the task_DvlpSeqTask - I think this is just before the JPEG image gets created.

How thoroughly have you tested this? I'd suggest

DNG in continuous mode
rawop / script hooks. drtest.lua is probably a reasonable test.
PTP remote shoot

Assuming this is robust, we should probably try to standardize on it for new ports (IIRC sx170 required it)

Logged

Don't forget what the H stands for.

srsa_4c

3920

Re: changelog of trunk including comments / devtalk

« Reply #233 on: 16 / August / 2015, 15:41:27 »

Quote from: reyalp on 16 / August / 2015, 15:15:40

we should probably try to standardize on it for new ports

Unfortunately, we can't. In new models, Canon appears to have abandoned dvlpseqtask (not completely, but the task is no longer called right after exposure). The JPEG creation process and file numbering is now initiated in captseqtask. I've seen this on the ixus160 (r55) and the ixus150 (r54). Some details can be found in the ixus160 porting thread.

Logged

Menu jumping/flickering on M10?

philmoz

3107

Re: changelog of trunk including comments / devtalk

« Reply #234 on: 16 / August / 2015, 19:33:54 »

Quote from: reyalp on 16 / August / 2015, 15:15:40

Quote from: philmoz on 10 / August / 2015, 21:29:58
Changeset 4220 & 4221 removes the need for PAUSE_FOR_FILE_COUNTER for the G1X, IXUS310 an SX40.

I moved the raw hook call to the task_DvlpSeqTask - I think this is just before the JPEG image gets created.
How thoroughly have you tested this? I'd suggest

DNG in continuous mode
rawop / script hooks. drtest.lua is probably a reasonable test.
PTP remote shoot

Assuming this is robust, we should probably try to standardize on it for new ports (IIRC sx170 required it)

I've tested all three scenarios.

The drtest.lua script never saves the last DNG file; but this happens even with the old PAUSE_FOR_FILE_COUNTER code on these cameras. It also never saves the last DNG for my G12 so I suspect it's a problem with the script or the hooks.

Phil.

Logged

CHDK ports:
sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
g12 (1.00c, 1.00e, 1.00f & 1.00g)
sx130is (1.01d & 1.01f)
ixus310hs (1.00a & 1.01a)
sx40hs (1.00d, 1.00g & 1.00i)
g1x (1.00e, 1.00f & 1.00g)

srsa_4c

3920

Re: changelog of trunk including comments / devtalk

« Reply #235 on: 28 / August / 2015, 20:51:13 »

I need some recommendation.

I have started adjusting the cpuinfo module to be compatible with ARMv7.
However, the amount of code that is architecture dependent is too big, so it should probably be split. Would it be acceptable if I split out the ARMv5 and v7 code to separate *.c files and include them in cpuinfo.c depending on the THUMB_FW define, or should this be handled in the makefile?

Logged

Menu jumping/flickering on M10?

reyalp

11923

Re: changelog of trunk including comments / devtalk

« Reply #236 on: 28 / August / 2015, 20:55:26 »

Quote from: srsa_4c on 28 / August / 2015, 20:51:13

I need some recommendation.

I have started adjusting the cpuinfo module to be compatible with ARMv7.
However, the amount of code that is architecture dependent is too big, so it should probably be split. Would it be acceptable if I split out the ARMv5 and v7 code to separate *.c files and include them in cpuinfo.c depending on the THUMB_FW define, or should this be handled in the makefile?

I'd probably just build the module from different C files in the makefile, but I don't feels strongly either way.

Logged

Don't forget what the H stands for.

srsa_4c

3920

Re: changelog of trunk including comments / devtalk

« Reply #237 on: 29 / August / 2015, 14:43:32 »

Quote from: reyalp on 28 / August / 2015, 20:55:26

I'd probably just build the module from different C files in the makefile, but I don't feels strongly either way.

Thanks, I proceeded as I originally intended. I also moved the asm function from the separate file to the arch-specific file and used assembler directives to control the instruction set. This method is not compatible with ARM modules, not sure if we'd ever want to build modules as ARM...

Logged

Menu jumping/flickering on M10?

reyalp

11923

Re: changelog of trunk including comments / devtalk

« Reply #238 on: 30 / August / 2015, 18:41:47 »

Quote from: philmoz on 16 / August / 2015, 19:33:54

The drtest.lua script never saves the last DNG file; but this happens even with the old PAUSE_FOR_FILE_COUNTER code on these cameras.

This should be fixed in 4231. It restored the users raw enable setting before the final shot started saving

Logged

Don't forget what the H stands for.

reyalp

11923

Re: changelog of trunk including comments / devtalk

« Reply #239 on: 30 / August / 2015, 18:52:45 »

Quote from: srsa_4c on 29 / August / 2015, 14:43:32

Thanks, I proceeded as I originally intended. I also moved the asm function from the separate file to the arch-specific file and used assembler directives to control the instruction set. This method is not compatible with ARM modules, not sure if we'd ever want to build modules as ARM...

This seems fine to me, I don't see any reason we would want to build the modules as arm, and if we did for a one off test, this one module being broken wouldn't be a big deal.

We have a general rule about not having ifdefs in models, but IMO the target CPU architecture should be an exception, because the resulting modules are incompatible anyway.

Logged

Don't forget what the H stands for.