Bug Reports against Recent Builds -- Report bugs here

[srsa_4c]

Since this is not the only recent report about battery display being broken, it may be related to changeset #1462:
Fix for incorrect types set on some config values (from tsvstar)
http://chdk.setepontos.com/index.php?topic=650.msg77680#msg77680
May be worth a look.

[philmoz]

Since this is not the only recent report about battery display being broken, it may be related to changeset #1462:
Fix for incorrect types set on some config values (from tsvstar)
http://chdk.setepontos.com/index.php?topic=650.msg77680#msg77680
May be worth a look.

You are correct, the changes in 1462 cause the problem.
The battery voltage values were not being initialised for a new install when no CCHDK.CFG file existed.

Should be fixed in 1490.

Phil.

[srsa_4c]

I think I've found something.

The original reporter of this bug was Gerhard34: link to post in CHDK-DE forum (german)
Running a certain script via ptp resulted in strange behaviour.
I could reproduce the problem as written in this post.
Since then I tried that script (with some -DE specific parts removed) with our stable version.

I've simplified the lua script to the following (I guess only the first line is needed):

Code: [Select]

set_record(1)
sleep(3000)
set_record(0)

When executed via ptp (on a recently switched-on camera), it acts like this:
A410, A430: camera switches to record mode, then immediately starts to zoom in (!)
Ixus65: camera switches to record mode, everything's normal

On one of the (earlier) test runs, the A410 crashed (the reason is probably unrelated). The earliest parts of the romlog look like this:
00064280: DispSwCon_TurnOnDisplayDevice
00064280: TerminateDeliverToZoomController
00064280: DSI_DisplayShootInfo( 0x20 )
00064280: STARTUP_OPTICAL_ZOOM_MAX_POSITION
00064290: PRESS_TELE_BUTTON
00064290: LogicalEvent:0x313d:adr:0x0,Para:0
00064290: _EntryStartRecMode
00064290: CaptModeChanger_CheckRTCRrepared
00064290: DispSwCon_MuteOffPhysicalScreen
00064290: MuteOffPhysicalScreen
00064290: _DecideModeDial

with at least the PRESS_TELE_BUTTON being suspicious.

I remembered to an svn commit by philmoz:
http://chdk.setepontos.com/index.php?topic=7045.msg75340#msg75340

In platform/generic/kbd.c (the A410 port uses this one) I changed this part:

Code: [Select]

static long kbd_new_state[3];
static long kbd_prev_state[3];
static long kbd_mod_state;
into

Code: [Select]

static long kbd_new_state[3] = { 0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFF };
static long kbd_prev_state[3] = { 0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFF };
static long kbd_mod_state = 0xFFFFFFFF;

With the above changes, the A410 stopped exhibiting that weird behaviour, no more zooming in after set_record(1).

The kbd.c code of the Ixus65 has kbd_mod_state initialized, and it never showed this problem.

May I ask a developer who knows the keyboard, ptp, scripting code, to look into this?

I suspect that some or all of those kbd_ variables need to be initialized, in every port...


update: http://chdk.wikia.com/wiki/Lua/PTP_Scripting
the above mentioned set_record() should not be used via ptp

Thx waterwingz, at least I was not completely wrong.

update2: No, I wasn't wrong, for VxWorks cameras, switch_mode_usb() is the same as set_record().

[waterwingz]

I suspect that some or all of those kbd_ variables need to be initialized, in every port...

This is very interesting as I've been chasing something similar for the USB remote upgrade.

I was seeing strange behavior on start-up when the USB remote was enabled using my new code.  On USB remote activation (5V) the lens would zoom out and / or a picture would be take even though the parts of USB remote code that could do that were disabled.  Curiously, if I pressed the Print key twice (going in and out of <ALT> mode) then the strange behavour stopped.    This was 100% repeatable.

My current conclusion is that some CHDK data is not initialized until <ALT> mode is enabled for the first time.  The modifications I had done to kbd.c were allowing code to run prior to <ALT> mode initialization.  In released versions of CHDK, that code had  previously not run prior to <ALT> mode being enabled.  This produced the strange behavior that I observed.

Specifically,  I was enabling the kbd_blocked state flag when the USB remote was active even though the camera was not in <ALT> mode.  (I've since changed that). Doing this after <ALT> mode has been entered once is acceptable - everything is intialized at that point.  Doing it before causes strange behaviour.

I'm wondering if this is related to the kbd_state variable you noticed ?   I'll look at it more tonight.


UPDATE : I can now confirm that initializing the 3 keyboard arrays solves the problem I had seen.  If nobody else does this first,  I'll make the change in the coming update to both kbd.c files to support the new remote USB code