CHDK PTP interface

asmodyne

reyalp

However, the basic frame buffer addresses and characteristics are already known for all complete ports, since they are required for histogram, zebra, md etc. There are some additional characteristics and special cases required for live view which that are *not* already in the code, and these will have to be added for each camera to enable full functionality. There is no way around this.

Tonight will be a long brawl between your trunk's code, Code Compare, and yours truly. 😛

asmodyne

Uuuh...since I'm not sure... the A540's base ROM address is 0xFFC00000, right ?

Fact is, the last program I used one can call a disassembler was running under MSDOS, and targeted 386 CPUs. 😳

So, I've done a little cross-check between three "sub/xxxx/lib.c" files, namely :

your A540 sub100b, from your live view port.
the A540 sub 100b "lib.c" from trunk 1672 .
the A430 sub 100b "lib.c" from trunk 1672 as well.

The main diff I noticed (apart from the platforms offsets, of course), is at the very end of your file :


// PTP display stuff
int vid_get_palette_type() { return 1; }
int vid_get_palette_size() { return 16*4; }

void *vid_get_bitmap_active_palette() {
    return (void *)0x634E0; // GetPaletteFromPhysicalScreen
}

void *vid_get_bitmap_active_buffer()
{
    return (void*)(*(int*)0x5ED0); // FFD23420 DisplayPhysicalScreenWithYUVPalette
}

Ask me to do some complicated hardware reverse engineering: fine, I've done it on a regular basis for the last 15 years or so...
Now, I'm so rusty at software reverse engineering I don't even know how to search a runtime ref to a hard-coded string with IDA. 😳
Anyway, that was just to state my current disasm skills... moldy 😉

Looking at the last two functions in your code, I obviously need to find the bitmap's palette and raster indices map offsets.
To do so, I have to locate any usage references about "GetPaletteFromPhysicalScreen" and "DisplayPhysicalScreenWithYUVPalette"... but DisplayPhysicalScreenWithYUVPalette doesn't even appear in the A540 dump ! I've run it through IDA: nothing ! Where did you find it reyalp ? 😖

reyalp

asmodyne
Uuuh...since I'm not sure... the A540's base ROM address is 0xFFC00000, right ?

Yes.

The main diff I noticed (apart from the platforms offsets, of course), is at the very end of your file :

FWIW, a better way to see what I've changed is http://trac.assembla.com/chdk/log/branches/reyalp-ptp-live (or check out the source with your favorite svn client and look at the logs and diffs)

To do so, I have to locate any usage references about "GetPaletteFromPhysicalScreen" and "DisplayPhysicalScreenWithYUVPalette"... but DisplayPhysicalScreenWithYUVPalette doesn't even appear in the A540 dump ! I've run it through IDA: nothing ! Where did you find it reyalp ? 😖

I don't actually remember 😳 Someone (probably me, possibly ewarv) found them a long time ago to support ewavrs chdkcam liveview code. That history can probably be found somewhere near the start of this thread...

DisplayPhysicalScreenWithYUVPalette appears to be something identified by the A series flirt sigs. See http://chdk.wikia.com/wiki/Loading_dump_to_IDA

But, since you have the address for one camera (the address in the comment is correct for a540), all you need to do is find some convenient landmark that identifies that code in the known dump, and then find the corresponding landmark in yours.

GetPaletteFromPhysicalScreen is an eventproc, so should be easier to find.

asmodyne

reyalp
FWIW, a better way to see what I've changed is http://trac.assembla.com/chdk/log/branches/reyalp-ptp-live...

Very useful indeed. I'm a noob with assembla. TIL something new about it, thanks reyalp ! 🧑‍🎄

reyalp
DisplayPhysicalScreenWithYUVPalette appears to be something identified by the A series flirt sigs. See http://chdk.wikia.com/wiki/Loading_dump_to_IDA

A-series indeed. I've just understood it's part of the VxWorks signatures semantic. Loading those 'old' signatures on both A540 and A430 ~~binaries~~ binary dumps helped me find it in less than an hour ! 😛
How could I live this long without using IDA before ? :😀

reyalp
GetPaletteFromPhysicalScreen is an eventproc, so should be easier to find.

Yup... found it almost instantly, thanks to the CHDK idc scripts. 😀

Excellent. I now have the offsets I missed in "./sub/lib.c". 😎As soon as I get my hand on the A430, I'll test it with your brand new ChdkPtp binary. I'm away from home for a week or so, and only brough a copy of my CHDK directory on a laptop.
brb (in a week max, maybe on Friday).

reyalp

asmodyne
Very useful indeed. I'm a noob with assembla. TIL something new about it, thanks reyalp ! 🧑‍🎄

If you are going to be working with the source, I strongly suggest getting tortoisesvn (assuming you are on windows) and checking out the code with it.

Excellent. I now have the offsets I missed in "./sub/lib.c". 😎

FWIW, you don't need any of these bitmap/palette functions for the most basic live view function.

waterwingz

reyalp
If you are going to be working with the source, I strongly suggest getting tortoisesvn (assuming you are on windows) and checking out the code with it.

Command line svn commands under Linux turn out to be not too bad. Still, the integration of TortoiseSVN into Windows that allows the file and directory icons in change to reflect their svn status is a nice feature I miss a lot. Yes, you get the same info with svn st chdk on the command line but its not the same somehow.

fe50

waterwingz
Still, the integration of TortoiseSVN into Windows that allows the file and directory icons in change to reflect their svn status is a nice feature

You may have a look to RapidSVN (http://rapidsvn.tigris.org/ ) for a Linux GUI.
I often use it with Windows, should work on Linux & Mac too.

The deep integration into the windows system is one thing i don't like with TortoiseSVN, with big projects sometimes it slows down a fast PC extremely. If anyway possible, i use all my software portable, without installation; this works with a lot of apps, also with software which isn't designed to run 'portable'.
For SVN, a nice solution for me is portable RapidSVN, running from a RAMdisk (also portable, of course) to speed up things & to hold off thousands of svn files from my hard discs 😉

asmodyne

Okay, I asked my other half to do an over-the-phone test of the modified CHDK, from your live-view trunk, reyalp.
Ain't I a resourceful lad ? 🤣

Anyway, the A430 responded nicely when asking for the UI overlay feed. But as soon as we ask for the viewfinder feed, the beast crashes.

Here is a screenshot of the live streamed UI :

The operations leading to this were :
1. Hit the 'Connect button
2. " " 'rec' button
3. "Live" tab -> Arbitrarily set "Target FPS" to 3.
4. "Debug" tab ->Checking "Dump to file"
5. Checking "UI Overlay" checkbox.
6. Waiting a bit, watching the seconds pass by on the UI capture.
7. Checking "Viewfinder" ... Mayday, device down.
Of course, dumping the stream didn't brough any light upon the issue, but ChdpPtp's console textbox gave some (presumably) meaningful info :

bm_max_width:360
bm_max_height:240
bm_buffer_width:360
lcd_ascpect_ratio:0
update_vidinfo: changed
vp_xoffset:nil->0
vp_yoffset:nil->0
vp_width:nil->720
vp_height:nil->240
vp_buffer_start:nil->0
vp_buffer_size:nil->0
bm_buffer_start:nil->44
bm_buffer_size:nil->86400
palette_type:nil->1
palette_buffer_start:nil->86444
palette_buffer_size:nil->64
palette:
0x00, 0x00, 0x00, 0x00, 0xff, 0xe0, 0x00, 0x00, 0xff, 0x3c, 0xde, 0x4a, 0xff, 0xb9, 0x00, 0x00,
0x7f, 0x00, 0x00, 0x00, 0xff, 0x6e, 0xa1, 0xa2, 0xff, 0xb2, 0x8c, 0x1f, 0xff, 0x5f, 0x00, 0x00,
0xff, 0x9a, 0xa9, 0x50, 0xff, 0x8a, 0x50, 0xb0, 0xff, 0x4b, 0x3d, 0xd4, 0xff, 0x23, 0x1b, 0xe2,
0x7f, 0x00, 0x7b, 0xe2, 0xff, 0x30, 0x00, 0x00, 0xff, 0x69, 0x00, 0x00, 0xff, 0x00, 0x00, 0x00,
recording to chdk_30f8_20120228_132726.lvdump

I suppose all those variable followed by a "nil->xxx" means the value was missing and replaced by default constants, right ?

reyalp

asmodyne
But as soon as we ask for the viewfinder feed, the beast crashes.

The camera, or the client ?

I suppose all those variable followed by a "nil->xxx" means the value was missing and replaced by default constants, right ?

Not quite. It only prints this when the information changes (since it would be bad to spam every frame). The x->y just tells you the old and new value. On the first frame, the "old" values are all nil. The code for this can be seen in lua/gui_live.lua in the chdkptp package.

I'm not clear if the information in the console comes from before crash (in which case, it tells us nothing) or relates to the data that caused the crash.

The camera may crash if the viewport address is incorrect or zero.

The camera may generate a romlog when it crashes, see http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29

watching the return value of vid_get_viewport_active_buffer may shed light on the situation (see misc debug vals in chdk core/gui.c ).

Note that you can enable "viewfinder" in playback mode, it will show you whatever picture is on the screen. This may fail (return null address, crash) if a video is selected.

asmodyne

reyalp

asmodyne
But as soon as we ask for the viewfinder feed, the beast crashes.

The camera, or the client ?

The camera crashes.

reyalp
I'm not clear if the information in the console comes from before crash (in which case, it tells us nothing) or relates to the data that caused the crash.

The console log here is what's written out before the device crashes. After that, the only thing updated is the console window, saying it received the bad return value 0x2FF, as it does anytime the A430 crashes for any reason whatsoever, while a ptp session's in progress.

reyalp
The camera may generate a romlog when it crashes, see http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29

watching the return value of vid_get_viewport_active_buffer may shed light on the situation (see misc debug vals in chdk core/gui.c ).

Nice ! I'll look into it. 😎

reyalp
Note that you can enable "viewfinder" in playback mode, it will show you whatever picture is on the screen. This may fail (return null address, crash) if a video is selected.

Excellent ! I assumed the record mode was a must for some reason. I'll try that. 😀

srsa_4c

Some observations, also on A430 ( with correct vid_get_bitmap_active_buffer() and vid_get_bitmap_active_buffer() ).
For me, it appears that when I select a target fps that cannot be reached, the chdkptp ui controls seem to freeze (start to lag, text no longer updates). Clicks on gui elements take effect after some (many seconds) delay when this happens. The camera hasn't crashed since I put the additional functions into lib.c (may be a coincidence).
Below values apply for still image (record) or play mode. Client runs on linux.

transferred[tt] [/tt]	max fps[tt] [/tt]	T/P avg kB/s[tt] [/tt]	Xfer last msec[tt] [/tt]	Xfer last kB/s[tt] [/tt]
viewfinder	3 (barely)	~755	~310	~810
ui overlay	4 (5 is unstable)	~337	~159	~530
both	2	~670	~415	~835

[hr]
Camera buttons on the gui have no effect until record mode is activated (but once that happens, they also work in play mode). After reconnecting to a running camera with a previously activated record mode the gui cam buttons also work.

asmodyne

srsa_4c
The camera hasn't crashed since I put the additional functions into lib.c (may be a coincidence).

Do you mean you actually got the Viewport stream up and running on A430 ? 😐:
If that's the case, may I ask you for a copy of your lib.c ? Pretty please ? :-*

srsa_4c

It's all related to the bitmap overlay:

void *vid_get_bitmap_active_buffer()
{
    return (void*)(*(int*)0x5EAC); // sub_ffd0cae8 DisplayPhysicalScreenWithYUVPalette
}

void *vid_get_bitmap_active_palette() {
    return (void *)0x714a8; // found also in sub_ffd0cae8
}

int vid_get_palette_type() { return 1; }
int vid_get_palette_size() { return 16*4; }

asmodyne

Well, I'll be damned !

here's what I used :

// PTP display stuff
int vid_get_palette_type() { return 1; }
int vid_get_palette_size() { return 16*4; }

void *vid_get_bitmap_active_palette() {
    return (void *)0x714A8; // GetPaletteFromPhysicalScreen
}

void *vid_get_bitmap_active_buffer()
{
    return (void*)(*(int*)0x5EAC); // loc_FF90CB50 DisplayPhysicalScreenWithYUVPalette for a430 with ROMSTART = 0xFF800000
}

same offsets...and nothing. No viewport stream without having the camera crashing.

I'll attach my complete inoperative lib.c, for reference's sake. It's a 100b sub, by the way.

lib.c

2.75KB

srsa_4c

@asmodyne

Are you using the latest reyalp-ptp-live branch with the latest chdkptp (I mean latest svn)?
If your only change was the code in your post, it should be the same as mine.

But it's not.
~~You only need those (the ones I and also you posted) additional lines in platform/a430/sub/100b/lib.c~~
vid_get_viewport_fb_d() also needs to be changed or else (as the comment says) playback mode with a movie selected will cause chdkptp's viewfinder transfer to fail.
Diff against reyalp-ptp-live

Index: platform/a430/sub/100b/lib.c
===================================================================
--- platform/a430/sub/100b/lib.c	(revision 1701)
+++ platform/a430/sub/100b/lib.c	(working copy)
@@ -46,7 +46,8 @@
 
 void *vid_get_viewport_fb_d()
 {
-    return (void*)(*(int*)0x71AB0); // @ffd0f29c
+    int x=(*(int*)0x71AB0); // @ffd0f29c
+    return (void*) (x ? x : vid_get_viewport_fb()) ;
 }
 
 long vid_get_viewport_height()
@@ -59,3 +60,15 @@
 {
     return (char*)0x7C588;
 } 
+
+void *vid_get_bitmap_active_buffer()
+{
+    return (void*)(*(int*)0x5EAC); // sub_ffd0cae8 DisplayPhysicalScreenWithYUVPalette
+}
+
+void *vid_get_bitmap_active_palette() {
+    return (void *)0x714a8; // found also in sub_ffd0cae8
+}
+
+int vid_get_palette_type() { return 1; }
+int vid_get_palette_size() { return 16*4; }

reyalp

srsa_4c
For me, it appears that when I select a target fps that cannot be reached, the chdkptp ui controls seem to freeze (start to lag, text no longer updates).

Yes, this is known. chdkptp is currently dumb, it just runs a timer to read usb and update the live view. This seems to behave particularly badly on linux when the code takes >= the timer interval.

Camera buttons on the gui have no effect until record mode is activated (but once that happens, they also work in play mode). After reconnecting to a running camera with a previously activated record mode the gui cam buttons also work.

This is normal. On newer (dryos ?) cameras you can use the magic post_levent_to_ui(4484) to unlock. For old cams, I believe switching to rec is the only known method.

I should make chdkptp send the unlock event for cams that support it, somehow.

edit:
I think your transfer rates are as expected for a usb 1 device.

asmodyne

@srsa_4c

from your diff code :

 long vid_get_viewport_height()
@@ -59,3 +60,15 @@
 {
     return (char*)0x7C588;
 }

What the actual... ??? What ? 😐:
So, we're truncating the 32bits reference 0x7C588 to a s8 or (s16*) referenece and return it as a s32 ? Is that it ? 😐:

Would you mean :

 long vid_get_viewport_height()
@@ -59,3 +60,15 @@
 {
     return (long)0x7C588; 
}

srsa_4c

@asmodyne
That was a unified diff. It has since been committed. Get a fresh svn copy, then see that lib.c 😀

asmodyne

srsa_4c
@asmodyne
That was a unified diff. It has since been committed. Get a fresh svn copy, then see that lib.c 😀

eeeeyup. I'll do that. 😉

PS : I'm SORRY srsa_4c ! :'( My apologies, if I ever lead readers to think this weird code could have been yours.

asmodyne

Soo, it seems that the live view works without problem. My "sugacube" 😁 said the average framerate hit 2.98 fps with ChdkPtp only asking for Viewport feed. I think we hit the A430's maximum usb bandwith here (it was the only device on the host's controller).

@reyalp

Next thing, I'll bring myself to undersand the mechanics of the view stream structure (if I want to decode it).
It's in your ChdkPtp/lua sources, izznit ?
I'll try to implement a proper way to pass the data container's payload directly to a pixel shader (to get an easy-to-use bitmap output).
Will I use DirectX or OpenGL, I still cannot say. I'm a tadbit inclined to use SharpGL though (i.e openGL).
Anyway, manipulating the live view frames stream is the GPU's job, IMO.
We'll see this weekend.

« Previous Page Next Page »