chdkptp - alternative ptp client - page 36 - General Discussion and Assistance

waterwingz

12138

Re: alternative ptp client

« Reply #350 on: 17 / May / 2013, 08:39:14 »

Advertisements

Quote from: reyalp on 17 / May / 2013, 01:10:51

Since this seems to affect other users, I'd like to understand it and find workarounds, but that's pretty hard without an affected system.

I run a somewhat hacked version of Fedora18 that uses xmonad under gnome as its desktop manager. USB automount does not work without a separate daemon - the details of how I got that working escape me at the moment.

So I guess this weekend I can try just running a straight "startx" after setting things to just boot to the command line. I think I can also run xmonad without gnome or maybe even another display manager ( IceWM ?).

Is there some additional information that could be dumped to the log window when one of the GUI buttons is pressed (and noting happens ...) ?

If I get a minute, I'll see if I can track down something that logs USB port activity more closely too.

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

14000

Re: alternative ptp client

« Reply #351 on: 17 / May / 2013, 16:04:28 »

Quote from: waterwingz on 17 / May / 2013, 08:39:14

So I guess this weekend I can try just running a straight "startx" after setting things to just boot to the command line. I think I can also run xmonad without gnome or maybe even another display manager ( IceWM ?).

Note this is not necessarily GUI related. udev rules run whether you are running X or not.

Quote

Is there some additional information that could be dumped to the log window when one of the GUI buttons is pressed (and noting happens ...) ?

Not really. Switching to rec mode is not special, it's just a lua function like any other. The fact that everything but switching to rec mode works as expected really means this is some internal camera state difference, not a client problem or a communication problem. As I explained in my previous post, ignoring keys like set, arrows etc is a separate, known issue (also due to camera state, not due to CHDK doing anything differently).

If you send

Code: [Select]

=switch_mode_usb(1)

to the camera, and there is no error but the camera doesn't switch, it clearly means this function is not behaving as it normally does. This is the firmware doing something different, not the client or CHDK doing something different. The USB connection is fine, the command was sent successfully, nothing in the client can tell the difference between this and any other function. As far as the client was concerned, everything worked fine, so there's really nothing to log.

Quote

If I get a minute, I'll see if I can track down something that logs USB port activity more closely too.

The kernel log (usually something like /var/kern.log and dmesg output) may have something.

A question, when you are connecting for the first time with chdkptp, do you get something like

Code: [Select]

open_camera_dev: ptp_opensession failed 0x2ff
open_camera_dev:usb_ptp_device_reset(): Device or resource busy
usb_ptp_get_device_status(): Device or resource busy
connected: Canon PowerShot D10, max packet size 512

If so, this means that something else had the camera open at the time. If not, that doesn't mean nothing touched it, but whatever it is probably doesn't have it open.

@frojnd
What distros / versions are you using, and what desktop?

Logged

Don't forget what the H stands for.

waterwingz

12138

Re: alternative ptp client

« Reply #352 on: 17 / May / 2013, 19:41:41 »

Quote from: reyalp on 17 / May / 2013, 16:04:28

Note this is not necessarily GUI related. udev rules run whether you are running X or not.

It came to me mid-day that I needed to remove the GUI from the equation. I discovered that running from a terminal window under Gnome, using =switch_mode_usb(1) or rec gets no reaction from the camera and no error messages on the command line.

So I changed my system default run level to 3 and rebooted into a base level console only mode. At that point chdkptp works fine - I can switch back and forth between playback and shooting modes and take pictures with the shoot command.

I'll see if I can get a simple X terminal mode only from the level 3 runlevel and try that.

Update : I do in fact get the error you asked about when running in a terminal window under gnome :

Code: [Select]

open_camera_dev: ptp_opensession failed 0x2ff
open_camera_dev:usb_ptp_device_reset(): Input/output error
usb_ptp_get_device_status(): Input/output error
connected: Canon PowerShot G10, max packet size 512

« Last Edit: 17 / May / 2013, 19:50:47 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

14000

Re: alternative ptp client

« Reply #353 on: 17 / May / 2013, 22:01:08 »

On my ubuntu system, I get something like this in dmesg output when I plug a camera in

Code: [Select]

[1027349.801292] usb 1-2: new high speed USB device using ehci_hcd and address 16
[1027349.953166] usb 1-2: configuration #1 chosen from 1 choice

Using this you can find the device associated with it. On my system, this comes out to /dev/bus/usb/001/016

We can see what has it open:

Code: [Select]

$ fuser /dev/bus/usb/001/016
/dev/bus/usb/001/016: 26824
$ ps -A | grep 26824
26824 ?        00:00:00 gvfsd-gphoto2

When I run chdkptp (producing the error messages in my earlier post), I get the following in dmesg

Code: [Select]

[1027736.312695] usb 1-2: usbfs: interface 0 claimed by usbfs while 'chdkptp' sets config #1
[1027736.312776] usb 1-2: usbfs: process 26990 (chdkptp) did not claim interface 0 before use
[1027736.312847] usb 1-2: usbfs: process 26990 (chdkptp) did not claim interface 0 before use
[1027736.312933] usb 1-2: usbfs: process 26990 (chdkptp) did not claim interface 0 before use
[1027736.430053] usb 1-2: reset high speed USB device using ehci_hcd and address 16

This is chdkptp stealing it from gvfsd-gphoto2.

Note that this "stealing" probably isn't the problem. Rather the problem is that whatever grabs the camera first is doing something that changes the camera state, like listing PTP objects.

Logged

Don't forget what the H stands for.

waterwingz

12138

Re: alternative ptp client

« Reply #354 on: 18 / May / 2013, 11:51:31 »

From a cold boot, once dmesg has settled down, I plug in my G10 and get this :

Code: [Select]

[   76.973571] usb 2-5: new high-speed USB device number 2 using ehci-pci
[   77.090927] usb 2-5: New USB device found, idVendor=04a9, idProduct=318f
[   77.090940] usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   77.090948] usb 2-5: Product: Canon Digital Camera
[   77.090954] usb 2-5: Manufacturer: Canon Inc.
[   77.090959] usb 2-5: SerialNumber: xxxxxxxxxxxxxxxxxxxxxxxxxx
[  122.265610] usb 2-5: reset high-speed USB device number 2 using ehci-pci
[  174.526315] usb 2-5: reset high-speed USB device number 2 using ehci-pci
[  317.464282] usb 2-5: reset high-speed USB device number 2 using ehci-pci

The last three lines are me going in & out of chdkptp.

Code: [Select]

[a@acer ~]$ fuser /dev/bus/usb/002/002
/dev/bus/usb/002/002:  1618
[a@acer ~]$ ps -A | grep 1618
 1618 pts/1    00:00:00 chdkptp
[a@acer ~]$

Using fuser shows chdkptp attaching, but there is nothing else there when I'm not in chdkptp. Perhaps gvfsd-gphoto2 exits right away?

Quote

Note that this "stealing" probably isn't the problem. Rather the problem is that whatever grabs the camera first is doing something that changes the camera state, like listing PTP objects.

So is there a "reset state" command that can be sent over ptp to the camera?

Just going into chdkptp in interactive mode, connecting and sending "rec" locks the camera up needing a battery reset. Its not crashed - my "Led blinker" task in the G10 is still running and blinking the power LED.

Also, at one point much earlier today I did see a dmesg message about gvfs-gphoto2-vo and "did not claim interface 0 before use" but I have not been able to reproduce it.

Update : using ps -A | grep gphoto I was able to find the pid for gvfs-gphoto2-vo and do a kill -s 15 1245. It seems to stay "killed" and now when I plug in my G10 I can use all of the chdkptp commands.

« Last Edit: 18 / May / 2013, 12:01:58 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

14000

Re: alternative ptp client

« Reply #355 on: 18 / May / 2013, 14:29:30 »

Quote from: waterwingz on 18 / May / 2013, 11:51:31

Using fuser shows chdkptp attaching, but there is nothing else there when I'm not in chdkptp. Perhaps gvfsd-gphoto2 exits right away?

The fact that you get the reset messages on the first connection suggests that something has it in use.

It's possible that the USB device appears at multiple paths (not via symlinks). You could look at
ls -l /proc/<pid of gvfs-gphoto2-vo>/fd to see what it has open.

Quote

So is there a "reset state" command that can be sent over ptp to the camera?

Your mission, should you choose to accept it...

I tried some combinations of post_levent_to_ui("DisconnectUSBCable");post_levent_to_ui("ConnectUSBCable") but the results were not good... camera hanging and needing power unplugged to restart. I haven't tried the post_levent_for_npt variants.

Alternately, you should be able to configure the gvfs-gphoto2 system somewhere to not automatically mount/scan the camera.

Anyway, this is all good information, at least we have a good idea why it's happening. Thanks for investigating.

Logged

Don't forget what the H stands for.

waterwingz

12138

Re: alternative ptp client

« Reply #356 on: 18 / May / 2013, 15:23:57 »

Quote from: reyalp on 18 / May / 2013, 14:29:30

Alternately, you should be able to configure the gvfs-gphoto2 system somewhere to not automatically mount/scan the camera.

http://www.freeklijten.nl/home/2011/06/04/Mounting-a-Canon-EOS-550d-on-Ubuntu-using-gphoto2#wl-comment-672

Following the above posting, I renamed the following files (the last one is different than what's in the post):

/usr/share/dbus-1/services/org.gtk.Private.GPhoto2VolumeMonitor.service /usr/share/gvfs/mounts/gphoto2.mount /usr/share/gvfs/remote-volume-monitors/gphoto2.monitor /usr/libexec/gvfs-gphoto2-volume-monitor

On reboot, the gvfs_gphoto_volume_monitor no longer runs and chdkptp works correctly.

But I'm not sure what else I've lost as a result.

« Last Edit: 18 / May / 2013, 15:54:19 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

14000

Re: alternative ptp client

« Reply #357 on: 18 / May / 2013, 16:11:41 »

Quote from: waterwingz on 18 / May / 2013, 15:23:57

On reboot, the gvfs_gphoto_volume_monitor no longer runs and chdkptp works correctly.

But I'm not sure what else I've lost as a result.

Probably file manager type browsing of PTP devices.

I would expect there there's a place where you can filter which devices are affected. (edit: i.e., one of those things you renamed is a shell script or something that decides which devices it wants to handle, or there is a conf file referenced by one that does the same)

edit:
fuse discussion moved to the ptp thread http://chdk.setepontos.com/index.php?topic=4338.msg100727#msg100727

« Last Edit: 18 / May / 2013, 17:58:06 by reyalp »

Logged

Don't forget what the H stands for.

frojnd

45

Re: alternative ptp client

« Reply #358 on: 21 / May / 2013, 18:59:02 »

Quote

What distros / versions are you using, and what desktop?

Archlinux on both computers with xmonad WM or lxde DE.

Logged

msl

1280
A720 IS, SX220 HS 1.01a

Re: alternative ptp client

« Reply #359 on: 02 / June / 2013, 15:51:41 »

I have played a little bit around the GUI. It's my first try to design some icons for IUP.Lua. All icons were converted with the program iupview.

All icons are in one extra file (gui_icon.lua). Some changes in gui.lua were necessary.

- old images from scratchpad deleted
- image tags for icons inserted
- function cam_btn() for icons changed
- slightly reformatted button area
- window dimension changed (height 560 instead 460 because different height of the tabs)
- small corrections
- added function for shoot+download with selection of a destination (user request from German forum)

msl

chdkptp_gui.zip (25.94 kB - downloaded 49 times.)

screenshot.png (44.85 kB, 733x560 - viewed 104 times.)

Logged

CHDK-DE: CHDK-DE links