chdkptp - alternative ptp client - page 91 - General Discussion and Assistance - CHDK Forum

chdkptp - alternative ptp client

  • 1106 Replies
  • 517578 Views
Re: alternative ptp client
« Reply #900 on: 07 / September / 2016, 17:23:27 »
Advertisements
Test SX60HS...updated to chdk to latest svn and rebuilt, updated chdkptp to latest and rebuilt...initially some problems:

1. I cannot see live view in record mode.  I get some errors, similar to what @Ant experienced.

x/chdkptp-svn/chdkptp/trunk/lua/gui_live.lua:527: width  > buffer_width
stack traceback:
   x/chdkptp-svn/chdkptp/trunk/lua/gui_live.lua:527: in function 'action'
   x/chdkptp-svn/chdkptp/trunk/lua/gui_live.lua:450: in function <x/chdkptp-svn/chdkptp/trunk/lua/gui_live.lua:419>
   [C]: in function 'xpcall'
   x/chdkptp-svn/chdkptp/trunk/lua/gui_live.lua:493: in function <x/chdkptp-svn/chdkptp/trunk/lua/gui_live.lua:491>
   (...tail calls...)
   [C]: in function 'MainLoop'
   x/chdkptp-svn/chdkptp/trunk/lua/gui.lua:758: in function <x/chdkptp-svn/chdkptp/trunk/lua/gui.lua:731>
   (...tail calls...)
   x/chdkptp-svn/chdkptp/trunk/lua/main.lua:280: in main chunk
   [C]: in function 'require'
   [string "require('main')"]:1: in main chunklive timer update error

2. Sometimes the background is not initialized to the correct YUV422 form,  I mean the UI overlay is fine but the background is pinkish.

I'm researching the problem.

Re: alternative ptp client
« Reply #901 on: 07 / September / 2016, 17:33:59 »
Fixed...I just need to merge my more recent lib.c with the old one edited by @reyalp.  I think it's time I checked in my changes....will clean and post on the SX60HS thread.

*

Offline reyalp

  • ******
  • 14082
Re: alternative ptp client
« Reply #902 on: 11 / September / 2016, 01:29:20 »
I have uploaded snapshot build r723 to the chdkptp files area: https://app.assembla.com/spaces/chdkptp/documents

See the changelog for details: https://app.assembla.com/spaces/chdkptp/wiki/Changelog

Significant changes include the d6 live view stuff described up thread, as well as some changes to the the binary distribution:

* All builds are now based on Lua 5.2.4, CD 5.10 and IUP 3.19.1
* Intel Linux binaries are provided for both 32 bit (-i686) and 64 bit (x86_64)
* Intel Linux binaries are now built on Debian Jessie 8.5
* Raspberry pi builds are built on Raspbian Jessie 8.0
* All Linux builds include both CLI and GUI executable, along with the required IUP and CD .so files for the GUI builds.
* The chdkptp.sh and chdkptp_gui.sh in the Linux packages should now set required environment variables automatically, and do not need to be edited.
* The chdkptp-raspbian-libs-….zip is no longer required to run the raspberry pi GUI. It is required if you want to build the GUI yourself.

I would be interested to know what success (or otherwise) people have running the linux builds. My hope is that at least most Debian heritage distros will be able to run them, but I haven't tested. edit: Verified it runs fine on ubuntu 16.04 x64

Side note: While making these builds, I found that chdkptp in a Linux virtualbox guest VM running under windows 10 is able to access cameras with reasonable performance and little hassle. Just right click on the USB icon on the VM window and select the camera. You probably want the Virtualbox "extra" package that includes USB 2.0 support for this.

I have only used this with cameras that already had the libusb driver installed on the windows side. If it wasn't installed, I suspect windows software would probably put the camera in the "black screen/unable to switch to rec" state before you can grab it in the VM.

I did have the VM USB die once in a way that made chdkptp hang for a long time and then fail when attempting to connect. This went away after a VM reboot.

edit:
not->now, thanks waterwingz
« Last Edit: 18 / September / 2016, 00:43:01 by reyalp »
Don't forget what the H stands for.

Re: alternative ptp client
« Reply #903 on: 11 / September / 2016, 08:12:59 »
* The chdkptp.sh and chdkptp_gui.sh in the Linux packages should not set required environment variables automatically, and do not need to be edited.
Is this supposed to say "should now set" ?
Ported :   A1200    SD940   G10    Powershot N    G16


*

Offline Ant

  • *****
  • 509
Re: alternative ptp client
« Reply #904 on: 11 / September / 2016, 10:04:47 »
I found a little problem:
Code: [Select]
> rmem 0x00000000  0x00100000 -f=ram.bin
ERROR: Protocol error: data expected
« Last Edit: 11 / September / 2016, 10:06:54 by Ant »

*

Offline srsa_4c

  • ******
  • 4451
Re: alternative ptp client
« Reply #905 on: 11 / September / 2016, 10:41:28 »
I found a little problem:
Code: [Select]
> rmem 0x00000000  0x00100000 -f=ram.bin
ERROR: Protocol error: data expected
NULL pointer protection. You can still crash your camera if you try accessing any of the first 32 bytes (or words?) of memory (which is protected on your camera).

*

Offline Ant

  • *****
  • 509
Re: alternative ptp client
« Reply #906 on: 11 / September / 2016, 11:15:59 »
I don't get crash typing:
Code: [Select]
> rmem 0x10  0x100000 -f=10.bin
0x00000010 1048576 10.bin

Whole RAM dumping also works from CHDK menu.
« Last Edit: 11 / September / 2016, 11:18:13 by Ant »

*

Offline reyalp

  • ******
  • 14082
Re: alternative ptp client
« Reply #907 on: 11 / September / 2016, 14:57:04 »
A low level tool like rmem probably doesn't need to protect you from things like this, but in any case the first few words generally have much you'd need to dump more than once.

It's not clear to me if the underlying send_ptp_data would handle NULL anyway, and on older cameras this is ITCM which doesn't always play nice if you try to DMA from it.

Quote
Whole RAM dumping also works from CHDK menu.
It has special code to read from the uncached address space instead (edit: although this should still on cameras with the first 32 bytes MPU protected). If you want to read the lowest values in physical RAM, you can do the same. On cameras where ITCM is mapped to 0, this is potentially not the same as the the ITCM contents.
« Last Edit: 11 / September / 2016, 15:04:28 by reyalp »
Don't forget what the H stands for.


*

Offline srsa_4c

  • ******
  • 4451
Re: alternative ptp client
« Reply #908 on: 11 / September / 2016, 15:54:04 »
I don't get crash typing:
Code: [Select]
> rmem 0x10  0x100000 -f=10.bin
0x00000010 1048576 10.bin
I don't see how this could work when the first 32 bytes are protected by the MPU...? Is there something wrong with the way CPUINFO decodes the MPU related data?
« Last Edit: 11 / September / 2016, 15:56:03 by srsa_4c »

*

Offline reyalp

  • ******
  • 14082
Re: alternative ptp client
« Reply #909 on: 11 / September / 2016, 16:02:58 »
I don't see how this could work when the first 32 bytes are protected by the MPU...? Is there something wrong with the way CPUINFO decodes the MPU related data?
Hmm, looking again I think it's only write protection:
Code: [Select]
  Access permission    0x5 5 [P:R- U:--]

=peek(0) works fine on g7x.
Don't forget what the H stands for.

 

Related Topics