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.
{ 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 },
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.
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.
2) Remove the SCN_ * vs non SCN_ versions
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.
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.
camera_info.state.mode_video = mode_is_video(mode);
I've spent some time studying this - looking for possible side effects. There are of course several.
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).
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.
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.
SoCode: [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.
Makes sense to me.
On camera with video button but with defined Canon modes that contain the 0x0400 video bit, everything works as before.
Started by Jure « 1 2 » General Discussion and Assistance
Started by msl « 1 2 » General Discussion and Assistance
Started by silver88 « 1 2 3 4 » Hello, I'm a NEWBIE - HELP!! (Newbies assistance, User Guides and thank you notes)
Started by waterwingz « 1 2 ... 22 23 » General Discussion and Assistance
Started by TMHKR General Help and Assistance on using CHDK stable releases
