Summarizing yesterdays observations:
The crash I found was due to permissions not allowing access to the device. This can also happen under debian based distros (see earlier comments on raspbian distro) but it appears that in depending on the distro usb_open returns NULL (arch case, ended up causing a segfault due to poor error checking in chdkptp) or it can succeed with only the later calls failing (raspbian case). All this should apply to ptpcam as well.
In changeset 273, I improved the error checking, so chdkptp should fail gracefully with an access denied error in the arch case.
Next question, why can't we access the USB device ?
It turns out, this is complicated under Linux, and varies depending on distro, version, desktop environment, whether the user is on the local desktop etc, what other ptp related packages are installed etc. Some references:
http://gphoto.org/doc/manual/permissions-usb.htmlhttps://wiki.archlinux.org/index.php/Digital_CamerasNote the above refer to gphoto2, but the same will generally apply to chdkptp. If you have gphoto2 installed, then checking whether you can connect to the camera with gphoto2 should be a good test (but note that installing libgphoto2 etc may affect how the camera is handled.)
More details:
udev is generally responsible for dealing with devices like this. In some configuration, udev sets the group on freshly plugged devices (this is the case on my Ubuntu 10.04 laptop). In other cases, something else (consolekit and systemd are mentioned on the arch page) are responsible.
On my arch install was headless and didn't have any of the consolekit stuff, so I attempted to set up a udev rule on arch to set the permissions. This lead me to another oddity:
The device appears on
/dev/usbdevN.M and /dev/bus/usb/N/M
both of these are actual devices, not symlinks. When I set group/mode in a udev rule e.g.:
ATTRS{idVendor}=="04a9", ATTRS{idProduct}=="311b", GROUP="camera", MODE="660"
This is applied the /dev/usbdev* device. However, both chdkptp and gphoto appear to use the /dev/bus/usb* device, so it doesn't solve the problem. Manually chmod'ing does the /dev/bus/usb* one does allow them to work. This should be possible using RUN to execute a shell script in the udev rule. I didn't get to test this yet because for some reason my arch install refuses to boot.
My laptop (again, older ubuntu) only has the /dev/bus/usb* device, and the default udev scripts installed change the group to plugdev and set the mode. chdkptp works out of the box for a normal user in this setup.
If someone knows more about why these different devices are used, I'd like to hear about it.
somewhat old guide to udev rules
http://www.reactivated.net/writing_udev_rules.htmlNote most of the commands mentioned are now sub-commands of udevadm
If you decide to write your own udev rules, keep in mind that the distros may have default rules which apply to the camera. These may appear in a variety of locations: on arch they appear in /etc/udev/rules.d, /lib/udev/rules.d, and /usr/lib/udev/rules.d
Edit:
for raspbian (Debian wheezy based), adding the following as /etc/udev/rules.d/40-chdkptp.rules allows me to use chdkptp as a standard user
ATTRS{idVendor}=="04a9", ATTRS{idProduct}=="311b", SUBSYSTEMS=="usb", ACTION=="add", MODE="0660", GROUP="plugdev"
311b is the pid, so that's the only thing that should need to change for other cameras.
This appears to set the permissions on both /dev/bus/usb/... and /dev/usbdev1...