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 :

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 ).

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)

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).

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 place1) Deal with the "video recording while in still" +1024 values.2) Remove the SCN_ * vs non SCN_ versions3) Remove bogus TX1 entries#1 can likely also be used to reliably detect video recording on some cameras.

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.

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 :

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

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.

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.

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.

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.

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.