Modemaps II: MODE HARDER (was Re: USB Remote Switch in CHDK ...)

waterwingz

12138

Modemaps II: MODE HARDER (was Re: USB Remote Switch in CHDK ...)

« on: 01 / January / 2015, 11:36:36 »

Advertisements

Quote from: srsa_4c on 01 / January / 2015, 11:17:47

I have a question: how is USB remote set to "onepush, normal" supposed to behave on a camera with dedicated video button? I'm getting the same result on the sx280 and the ixus115: when the camera is in one of the movie modes, applying power to USB starts a recording which then can't be stopped with buttons or the remote. Is this a camera specific bug or am I missing something?

edit:
All buttons become unresponsive except for the "ON/OFF" button (which is not in KEYS_MASKx).
CHDK 1.3 r3449 on the sx280, 1.4 r3863 on the ixus115.

Looking at it now. The S100 does the same thing. At the time I wrote that code, I did not have a camera with a seperate video button.

update 1: strange. The camera_info.state.mode_video value changes from 1 to 0 when recording starts even though the mode dial is still set to video. This throws off the USB state machine sequencing as it thinks the camera is no longer in video mode. Tracking down what happens in mode_is_video() now

update 2: the Canon mode map value changes from 2622 ( 0x0A3E) MODE_VIDEO_STD to 3646 (0x0E3E) when the video button is pressed. As 3646 is not in the mode_map[] table, the CHDK mode goes to zero. Which is what causes the USB remote code to lock up. Not sure how to fix that without risking breaking something else in that whole house of cards.

update 3 : changing the video part of the mode map initialization to cover both cases in video mode solves this :

Code: [Select]

    { MODE_VIDEO_STD,            3646 },
    { MODE_VIDEO_STD,            2622 },
    { MODE_VIDEO_IFRAME_MOVIE,   2629 },
    { MODE_VIDEO_IFRAME_MOVIE,   3653 },    
    { MODE_VIDEO_SUPER_SLOW,     2627 },
    { MODE_VIDEO_SUPER_SLOW,     3651 },

However, to make this work for all cameras with dedicated video button, every one of their mode maps will need an update.

Masking the Canon mode with 0x100 should do the same thing for video modes but may corrupt the other modes? Messy.

I suppose the USB output module logic could be hacked to ignore mode changes when remote activated sequences are in operation. But that's a bass ackwards way to fix the problem.

« Last Edit: 04 / October / 2015, 20:00:29 by reyalp »

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

14000

Re: Modemaps II: MODE HARDER

« Reply #1 on: 01 / January / 2015, 14:55:28 »

Quote from: waterwingz on 01 / January / 2015, 11:36:36

update 2: the Canon mode map value changes from 2622 ( 0x0A3E) MODE_VIDEO_STD to 3646 (0x0E3E) when the video button is pressed. As 3646 is not in the mode_map[] table, the CHDK mode goes to zero. Which is what causes the USB remote code to lock up. Not sure how to fix that without risking breaking something else in that whole house of cards.

Yes, this is long standing unfinished business in the mode map code. Most (all?) cameras that can start recording while in a still mode add 1024 to the current mode, and CHDK doesn't handle this at all... except for some some weird modes created for the TX1 port like MODE_VIDEO_PORTRAIT, which originally meant "recording video while in portrait still mode", or something like that (before my time

).

This really ought to be cleaned up, but I've been leaving it alone since no one had complained and I didn't see a way to deal with it without breaking compatibility. Backstory http://chdk.setepontos.com/index.php?topic=3228.msg43452#msg43452

Having multiple definitions for the same CHDK mode number in the mode map seems less then ideal. Having modes that can't actually be set also doesn't seem good (i.e setting X+1024 doesn't actually put you in a video mode or start recording)

Logged

Don't forget what the H stands for.

waterwingz

12138

Re: Modemaps II: MODE HARDER

« Reply #2 on: 01 / January / 2015, 15:25:59 »

Quote from: reyalp on 01 / January / 2015, 14:55:28

Most (all?) cameras that can start recording while in a still mode add 1024 to the current mode, and CHDK doesn't handle this at all...

FYI in this case, the camera mode dial was in then "video" position. (That position seems to be only useful for selecting between regular, super slow, and iFrame modes as you still have to press the video button to start recording).

Starting recording in that mode also causes the mode to change.

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

14000

Re: Modemaps II: MODE HARDER

« Reply #3 on: 01 / January / 2015, 17:17:20 »

Quote from: waterwingz on 01 / January / 2015, 15:25:59

FYI in this case, the camera mode dial was in then "video" position. (That position seems to be only useful for selecting between regular, super slow, and iFrame modes as you still have to press the video button to start recording).

Starting recording in that mode also causes the mode to change.

Oh, I missed that detail. It seems masking out the 1024 in mode_get should be generally OK, both for recording in still, and ones that change VIDEO_STD. That would make it return the actual mode value, which seems correct. This might be the thing to do for 1.4, the risk of unforeseen side effects seems high for 1.3.

mode_is_video is problematic, since it doesn't have any concept of a still mode where you can also record video. Really there needs to be a way to tell "can I record video in the current mode" and "can I take stills in the current mode".

--
edit: related items copied from 1.4 planning thread to have everything in one place
1) Deal with the "video recording while in still" +1024 values.
2) Remove the SCN_ * vs non SCN_ versions
3) Remove bogus TX1 entries
#1 can likely also be used to reliably detect video recording on some cameras.

« Last Edit: 01 / January / 2015, 17:23:33 by reyalp »

Logged

Don't forget what the H stands for.

philmoz

3449

Re: Modemaps II: MODE HARDER

« Reply #4 on: 02 / January / 2015, 01:37:51 »

Quote from: reyalp on 01 / January / 2015, 17:17:20

2) Remove the SCN_ * vs non SCN_ versions

Attached patch:
- merges MODE_SCN_ABC and MODE_ABC to just MODE_ABC
- renames remaining MODE_SCN_XYZ to MODE_XYZ
- groups and sorts the entries in modelist.h

May break some scripts; but I don't think there is any way around that.

If this is what you were looking for, then I'll add it to SVN.

Phil.

modelist.diff (217.12 kB - downloaded 26 times.)

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)
g5x (1.00c, 1.01a, 1.01b)
g7x2 (1.01a, 1.01b, 1.10b)

reyalp

14000

Re: Modemaps II: MODE HARDER

« Reply #5 on: 02 / January / 2015, 02:10:13 »

Quote from: philmoz on 02 / January / 2015, 01:37:51

May break some scripts; but I don't think there is any way around that.

Yeah, me neither. I suspect the number of scripts relying on weird scene modes is fairly low, and the important ones like Auto, M and P shouldn't change. We we might be able to make capmode backward compatible with the names, but I'm not sure it's worth it.

Quote

If this is what you were looking for, then I'll add it to SVN.

That's what I had in mind. Thanks!

Logged

Don't forget what the H stands for.

waterwingz

12138

Re: Modemaps II: MODE HARDER

« Reply #6 on: 12 / January / 2015, 21:13:47 »

Quote from: reyalp on 01 / January / 2015, 17:17:20

It seems masking out the 1024 in mode_get should be generally OK, both for recording in still, and ones that change VIDEO_STD. That would make it return the actual mode value, which seems correct. This might be the thing to do for 1.4, the risk of unforeseen side effects seems high for 1.3.

I've spent some time studying this - looking for possible side effects. There are of course several.

Attached is a spreadsheet analysis of all the CapturemodeMap modemap[] values currently defined.

If we mask the Canon mode value from PROPCASE_SHOOTING_MODE used in core/shooting.c/mode_get() with ~0x400 (so that the reported mode value does not change when cameras with a video button start recording), then only eleven cameras are potentially affected. The change will have no effect for cameras without video buttons. It will also change nothing for 35 of the cameras that do have video buttons (other than letting mode_get() return the actual current mode).

That leaves nine cameras that could perform differently if this patch is made. These are :

A1300, A810, ixus132_elph115, ixus135_elph120, N, N_Facebook, sx1, sx10, tx1.

The a420 and a430 might also be affected but they do not have a video button so I suspect their definitions for MODE_VIDEO_STD are wrong.

If we just apply the attached patch (works on 1.3.0 and 1.4.0) then everything seems to work for all cameras (specifically the USB remote bug srsa_4c originally noticed). The MODE_VIDEO_STD defines for the 11 cameras will simply be ignored as will the extra mode definition used by the TX1. This might be a problem for the A1300, which does not appear to have a video mode other than that involved by pressing the video button. So

Code: [Select]

camera_info.state.mode_video = mode_is_video(mode);will never be true for that camera. Perhaps that makes sense as it does not have a video mode technically?

Conclusion : masking the 0x0400 bit in PROPCASE_SHOOTING_MODE will have minimal possible side effects and will fix a glaring hole for cameras with video buttons whereby their mode is reported as NULL when video recording is in progress.

Edit : tested on the S100 and Powershot N to confirm this "fixes" the original error reported by srsa_4c.

mode_nums_r2.ods (144.38 kB - downloaded 26 times.)

video_modemask_v1.patch (0.61 kB - downloaded 28 times.)

« Last Edit: 12 / January / 2015, 22:16:17 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

14000

Re: Modemaps II: MODE HARDER

« Reply #7 on: 12 / January / 2015, 22:47:39 »

Quote from: waterwingz on 12 / January / 2015, 21:13:47

I've spent some time studying this - looking for possible side effects. There are of course several.

Thanks

Quote

If we mask the Canon mode value from PROPCASE_SHOOTING_MODE used in core/shooting.c/mode_get() with ~0x400 (so that the reported mode value does not change when cameras with a video button start recording), then only eleven cameras are potentially affected. The change will have no effect for cameras without video buttons. It will also change nothing for 35 of the cameras that do have video buttons (other than letting mode_get() return the actual current mode).

FWIW, on d10 (and presumably others) you can set the print button to act like a video button in the canon firmware. This has the same +0x400 behavior as a real video button, so I don't think it changes the conclusion.

Quote

The a420 and a430 might also be affected but they do not have a video button so I suspect their definitions for MODE_VIDEO_STD are wrong.

To take care of oddballs, we could make VID_REC_ACTIVE_BIT a camera.h define, which defaults to 0x400. Looking at the comments in a420, it seems like someone (srsa?) actually tested this and the camera does show 0xe1d when in video mode. Setting VID_REC_ACTIVE_BIT 0 for this camera would keep the original behavior.

Quote

This might be a problem for the A1300, which does not appear to have a video mode other than that involved by pressing the video button.

This is true of elph130 as well, and probably some other recent cameras too.

Quote

So
Code: [Select]
camera_info.state.mode_video = mode_is_video(mode);will never be true for that camera. Perhaps that makes sense as it does not have a video mode technically?

That's how elph130 is, there is no video mode in the mode map.

Quote

Conclusion : masking the 0x0400 bit in PROPCASE_SHOOTING_MODE will have minimal possible side effects and will fix a glaring hole for cameras with video buttons whereby their mode is reported as NULL when video recording is in progress.

Makes sense to me.

Logged

Don't forget what the H stands for.

waterwingz

12138

Re: Modemaps II: MODE HARDER

« Reply #8 on: 12 / January / 2015, 23:24:38 »

Quote from: reyalp on 12 / January / 2015, 22:47:39

Makes sense to me.

One fancy refinement to this (that I played with but did not resolve completely) would be to let mode_is_video() in shooting.c return true if the 0x0400 bit it set. That would be in addition to the current checks for being in a VIDEO mode.

Seems to make sense at that level of the code but I wasn't able to tell how that would play out elsewhere.

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

14000

Re: Modemaps II: MODE HARDER

« Reply #9 on: 13 / January / 2015, 23:36:20 »

From the patch thread

Quote

On camera with video button but with defined Canon modes that contain the 0x0400 video bit, everything works as before.

Keeping the existing behavior for 1.3 is makes sense, but I suspect many of these are spurious. e.g on cameras like a1300 MODE_VIDEO_STD is defined as 33792 (AUTO + 1024). From the manual, it doesn't look there is actually a video mode you can set, so presumably it just gets the +1024 of whatever mode you are in when you start recording video.

If you can't switch to VIDEO_STD with set_capture_mode, then it should be removed, in the trunk at least.

Logged

Don't forget what the H stands for.