Testing cameras after kbd.c change: 27 tested | 2 with minor bugs - page 5 - General Discussion and Assistance - CHDK Forum
supplierdeeply

Testing cameras after kbd.c change: 27 tested | 2 with minor bugs

  • 89 Replies
  • 24542 Views
*

Offline koshy

  • *****
  • 1063
Advertisements
IXUS i Zoom

- iZ boots a current CHDK 1.4
- FW doesn't show "card locked" message
- keys outside of alt mode work
- has no dial
- keys in ALT mode work fine
- shooting RAW / JPEG was fine
- USB remote was fine (see note below)
- CHDKPTP spot check of buttons was fine

In CHDKPTP wheel buttons do nothing and cause no trouble

Note on USB Remote: The cam only has the odd wide connector for its charging bowl and the bowl has the USB connector. When the cam is in the bowl it won't go to Rec mode unless told to by CHDKPTP. So, in order to test USB Remote I connected by CHDKPTP, went to Rec, disconnected, set the remote options up and could then use them (using the remote on the bowl's usb port). So yeah it works.
Koshy had a little ELPH which wasn't white as snow but everywhere that Koshy went the ELPH was sure to go. (actually an SD, but that detail ruins the rhyme...)

*

Offline reyalp

  • ******
  • 13391
As a general question: Is it relavant that on some cameras without a jogdial or "touch control dial" the "wheel l" and "wheel r" buttons work in executing left / right movement while for some others they just don't do anything? I didn't mention where they don't work if the camera has no dial but just noticed on the I750 that the buttons worked so I was wondering that.
Oh that's a good catch. For reasons I don't remember, chdkptp actually uses post_levent like
post_levent_to_ui("RotateJogDialLeft",1)

instead of calling CHDK wheel_left and wheel_right script functions. So it works if the Canon firmware recognizes it, which I guess some non-jogdial cameras do.

Unfortunately, this also means that testing the GUI buttons didn't tell us if the script wheel_left and wheel_right functions work correctly.

If you want to add
=wheel_left()
=wheel_right()
to your tests, that would verify the CHDK functions. However, it's pretty unlikely that the keyboard changes would have broken these, so it's OK if you don't want to, and you don't need to go back and retest the cams already done.

Quote
Note on USB Remote: The cam only has the odd wide connector for its charging bowl and the bowl has the USB connector. When the cam is in the bowl it won't go to Rec mode unless told to by CHDKPTP. So, in order to test USB Remote I connected by CHDKPTP, went to Rec, disconnected, set the remote options up and could then use them (using the remote on the bowl's usb port). So yeah it works.
This is interesting, in previous discussion about this camera http://chdk.setepontos.com/index.php?topic=11723.msg114947#msg114947 it wasn't clear the USB remote could be made to work at all.

This is a very old/unique camera, so if you don't want to mess with it more that's fine. Anyone who wants to actually use it can be directed to these threads. Information for future reference below...

From the above, I think there is a separate way the camera detects whether it is in the bowl (cradle), independent of the the USB bit. There is a good chance this is another physw bit. Based on the old thread, the USB bit is 0x08000000 in physw word 1 (and works, per your test above), and the other bit (if it exists) is NOT in word 1.

If you want to look at the other two words of physw_status in this camera without the bowl, that might be interesting. To do this, you can use the memory browser and look at 0x10FF0 and 0x10FF8 with and without the camera in the cradle.

There are also some possibly related event procs.
UiEvnt_StartDisguiseCradleStatus
UiEvnt_StopDisguiseCradleStatus
UIFS_SetCradleSetting

These functions would (probably) be registered with call_event_proc'UI_RegistDebugEventProc' and may need set_levent_script_mode(1) before taking effect.

And levents
AttachCradle
DetachCradle

it's possible that post_levent_to_ui'DetachCradle' will allow normal mode switching.
Don't forget what the H stands for.

*

Offline koshy

  • *****
  • 1063
Quote
Note on USB Remote: The cam only has the odd wide connector for its charging bowl and the bowl has the USB connector. When the cam is in the bowl it won't go to Rec mode unless told to by CHDKPTP. So, in order to test USB Remote I connected by CHDKPTP, went to Rec, disconnected, set the remote options up and could then use them (using the remote on the bowl's usb port). So yeah it works.
This is interesting, in previous discussion about this camera http://chdk.setepontos.com/index.php?topic=11723.msg114947#msg114947 it wasn't clear the USB remote could be made to work at all.

This is a very old/unique camera, so if you don't want to mess with it more that's fine.
Unique is always fascinating. We can mess with it some more if you're interested.
I checked and obviously what worked today I couldn't get to work before. Well, I wrote an update here, too:
http://chdk.setepontos.com/index.php?topic=11723.msg114974#msg114974

On the things you suggested I'll need step by step instructions.

I figured that the memory browser would be located under CHDK menu > Misc. Stuff > Debug Parameters but it is not there.

BTW: If I choose CHDK menu > Misc. Stuff > Tools the cam crashes - repeatably - but I don't get a crash log afterwards.
Koshy had a little ELPH which wasn't white as snow but everywhere that Koshy went the ELPH was sure to go. (actually an SD, but that detail ruins the rhyme...)

*

Offline reyalp

  • ******
  • 13391
For ixus960 touch dial problem:

Can you please check if touching affects physw_status?

You can use the memory browser to watch 0x14cfc, 0x14d00, 0x14d04, or use
rmem -i32 0x14dcfc 3
rmem -i32 0x14cfc 3

in chdkptp.

If there are bits affected by touch, they will probably all be in the same word and be close together.

edit:
Memory browser is now in tools, will need to look into crash on izoom.
« Last Edit: 06 / June / 2015, 18:26:59 by reyalp »
Don't forget what the H stands for.


*

Offline koshy

  • *****
  • 1063
For ixus960 touch dial problem:
Can you please check if touching affects physw_status?

You can use the memory browser to watch 0x14cfc, 0x14d00, 0x14d04, or use
rmem -i32 0x14dcfc 3
in chdkptp.

If there are bits affected by touch, they will probably all be in the same word and be close together.
The CHDKPTP method was easier. I tried with the memory browser but could not make sense of what I was seeing for the three addresses. Anyway, here is the CHDKPTP output

> rmem -i32 0x14dcfc 3
0x0014dcfc 12
0x0014dcfc: 0x6c7f9468 0x99747698 0x69967d6e
0x0014dcfc: 0x6c7f9468 0x99747698 0x69967d6e
0x0014dcfc: 0x6c7f9468 0x99747698 0x69967d6e
0x0014dcfc: 0x6c7f9468 0x99747698 0x69967d6e
0x0014dcfc: 0x6c7f9468 0x99747698 0x69967d6e

I obviously removed the commands and "0x0014dcfc 12" for the subsequent calls. The first line is without touching, the four attempts thereafter are queried while toucing the touch control dial so that it shows. I think there is no change. To be sure I tried a few times as fiddling with the dial and querying at the same time can be tricky.
Koshy had a little ELPH which wasn't white as snow but everywhere that Koshy went the ELPH was sure to go. (actually an SD, but that detail ruins the rhyme...)

*

Offline reyalp

  • ******
  • 13391
Sorry, I had a typo in rmem address. Try

rmem -i32 0x14cfc 3

For the memory browser, the DWORD value would be the one you are interested in. To set the address, zoom controls the increment (Incr: value) and arrows adjust the address.
Don't forget what the H stands for.

*

Offline koshy

  • *****
  • 1063
For the memory browser, the DWORD value would be the one you are interested in. To set the address, zoom controls the increment (Incr: value) and arrows adjust the address.
O.k. then I had figured out how to use it but the values kept fluctuating all the time.

"@" is what's unstable:  0x00014cfc: 0xd@@cdf74 0x@1c40@2@ 0x00248fff

Here are a few examples from CHDKPTP:

> rmem -i32 0x14cfc 3
0x00014cfc 12
0x00014cfc: 0xd06cdf74 0x21c40e2a 0x00248fff
0x00014cfc: 0xd12cdf74 0x21c4052a 0x00248fff
0x00014cfc: 0xd32cdf74 0x21c4052a 0x00248fff
0x00014cfc: 0xd1acdf74 0x71c4052a 0x00248fff
0x00014cfc: 0xd0ecdf74 0x21c40e22 0x00248fff
0x00014cfc: 0xd2ecdf74 0x21c4052a 0x00248fff
0x00014cfc: 0xd26cdf74 0x61c40e22 0x00248fff

Using the memory browser I can say that none of the stable portions change upon using the touch control dial.
Koshy had a little ELPH which wasn't white as snow but everywhere that Koshy went the ELPH was sure to go. (actually an SD, but that detail ruins the rhyme...)

*

Offline koshy

  • *****
  • 1063
G7

- G7 boots a current CHDK 1.4
- FW doesn't show "card locked" message
- keys outside of alt mode work
- has a jogdial
- keys and jogdial work fine in ALT mode
- shooting RAW / JPEG was fine
- USB remote was fine
- CHDKPTP spot check of buttons was fine including wheel buttons
- =wheel_left() =wheel_right() worked fine

Another camera that doesn't have a full PTP live view implementation.
Koshy had a little ELPH which wasn't white as snow but everywhere that Koshy went the ELPH was sure to go. (actually an SD, but that detail ruins the rhyme...)


*

Offline reyalp

  • ******
  • 13391
Using the memory browser I can say that none of the stable portions change upon using the touch control dial.
Thanks. Looks like we can't get touch bits out of physw_status on this ixus960.

Here's a test patch.
Don't forget what the H stands for.

*

Offline koshy

  • *****
  • 1063
There is a good chance this is another physw bit. Based on the old thread, the USB bit is 0x08000000 in physw word 1 (and works, per your test above), and the other bit (if it exists) is NOT in word 1.

If you want to look at the other two words of physw_status in this camera without the bowl, that might be interesting. To do this, you can use the memory browser and look at 0x10FF0 and 0x10FF8 with and without the camera in the cradle.
I have been using CHDK 1.3 for the memory browser. I found that:

0x10FF0: 0x00000000
0x10FF8: 0x0000FFFF

both inside and outside the cradle. However I was not able to see the USB bit I had identified before. What would its address be? Nafraf had made me a patch back then so that I just used the "Show misc. Values" feature I think.
« Last Edit: 06 / June / 2015, 20:27:45 by koshy »
Koshy had a little ELPH which wasn't white as snow but everywhere that Koshy went the ELPH was sure to go. (actually an SD, but that detail ruins the rhyme...)

 

Related Topics