Bug 429173 - gphoto2 can't communicate with Canon PowerShot S400 - how to fix
Summary: gphoto2 can't communicate with Canon PowerShot S400 - how to fix
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: gphoto2
Version: 8
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Jindrich Novy
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-01-17 18:44 UTC by David A. De Graaf
Modified: 2013-07-02 23:26 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-01-09 07:35:47 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description David A. De Graaf 2008-01-17 18:44:19 UTC
Description of problem:
gphoto2 can't communicate with my camera

Version-Release number of selected component (if applicable):
gphoto2-2.4.0-4.fc8


How reproducible:
Perfectly

Steps to Reproduce:
1.  Connect the camera with USB cable; turn it on; notice that it's detected.
2.  Run  gphoto2 --get-all-files
3.
  
Actual results:
Error message:  Communication failure

Expected results:
Proper transfer of files.


Additional info:

The ghoto2 program used to be able to communicate with my Canon
PowerShot S400 camera (lsusb:  ID 04a9:3075 Canon, Inc. IXUS 400 Camera)
while connected via a USB cable and to download the image files.
In recent distributions - after ~Fedora 6 - it stopped working.

There are two reasons:
1)  The udev system sets permissions stupidly (in my opinion) making
it impossible for non-root users to access USB devices.
2)  A timeout setting in the gphoto2 libraries is too short, causing
communication to fail.

Here's what I did to fix it:

1)  To liberalize udev to a state of usefulness, make changes in
/etc/udev/rules.d/:

  $ diff 40-redhat.rulesSTD 40-redhat.rules
  12c12
  < BUS=="usb", KERNEL=="sd*", ATTRS{bInterfaceClass}=="08",
  ATTRS{bInterfaceSubClass}=="04", GROUP="floppy", MODE="0660",
  SYMLINK+="floppy floppy-%k"
  ---
  > BUS=="usb", KERNEL=="sd*", ATTRS{bInterfaceClass}=="08",
  ATTRS{bInterfaceSubClass}=="04", GROUP="floppy", MODE="0666",
  SYMLINK+="floppy floppy-%k"
  
  
  $ diff 50-udev-default.rulesSTD 50-udev-default.rules
  13c13
  < KERNEL=="tty[A-Z]*|pppox*|ircomm*|noz*", GROUP="uucp"
  ---
  > KERNEL=="tty[A-Z]*|pppox*|ircomm*|noz*", GROUP="uucp", MODE="0666"
  52c52
  < SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device",
  NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0644"
  ---
  > SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device",
  NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0666"


These changes give 0666 permissions to USB devices and ttyS?
at the next reboot.  This allows me, or anyone, to actually use the
camera, a USB memory stick, or my GPS plugged into the serial port.


2)  To fix the gphoto2 timeout, only one line needs to change in
/usr/local/src/gphoto2//libgphoto2-2.4.0/camlibs/canon/usb.c

  $ diff usb.cSTD usb.c
  75c75
  < #define CANON_FAST_TIMEOUT 75
  ---
  > #define CANON_FAST_TIMEOUT 500

However, this entails obtaining and building and installing
libusb-0.1.12.tar.gz, libgphoto2-2.4.0.tar.bz2 and
gphoto2-2.4.0.tar.bz2.  The resulting software will be installed in
/usr/local/bin and /usr/local/lib.


It is impractical to remove the standard gphoto2-2.4.0-4.fc8 rpm
package by the usual method
    rpm -e gphoto2
due to a huge list of dependencies.  To ensure that the new
stuff in /usr/local is used, I had to violate the rules that says rpm
is in charge of all system files.  I renamed
    /usr/bin/gphoto2  ->  /usr/bin/RPM.gphoto2
and in /usr/lib,  all libgphoto*  ->  RPM.libgphoto*

This makes all the standard files inaccessible.

Then to make sure the new /etc/local/lib/libghoto* files are used
I added /etc/ld.so.conf.d/gphoto2.conf containing this one line:
  /usr/local/lib

and ran  ldconfig -v  and verified that the new libraries will be used.


Now gphoto2 works again; and so does gthumb - it can once again import
photos from the camera.

Whew!

Wouldn't it be wonderful if this simple timeout value could be
changed, and a major rethinking of the udev concept be made to allow
Linux to be easy to use, instead of such a damnable hassle.

Comment 1 Jindrich Novy 2008-01-18 12:28:28 UTC
There shouldn't be problem in increasing the timeout value in gphoto2.

Harald, do the proposed changes in udev make sense? Is it possible to add them?

Comment 2 Harald Hoyer 2008-01-18 12:53:36 UTC
MODE="0666" does not make sense.. either pam_console or PolicyKit should grant
you access to the devices.

Comment 3 David A. De Graaf 2008-01-18 17:52:18 UTC
pam_console ???   You're kidding.   Right?

PolicyKit ???

$ man PolicyKit
No manual entry for PolicyKit

$ whereis PolicyKit
PolicyKit not found in normal places

$ apropos PolicyKit
PolicyKit: nothing appropriate

# yum list available "PolicyKit*"
   ...
Error: No matching Packages to list


I've tried to ignore pam_console ever since it reared its ugly head a
few years ago.  Now you've forced me to read about it.

What an ugly concept.  The basic premise is just so totally out of
place in a Linux world - "designed to give users at the physical console
... capabilities  that they would not otherwise have, and to take those
capabilities away when the are no longer logged in at the console."

My computer is physically under my control.  In fact, the entire machine
sits on my lap - it's a laptop.  All my computers are under my direct
physical control.  Yes, I can and do sometimes log in with different
userids at the same time on different consoles or even X servers, and I
do not want the computer to restrict whether certain devices can be used.
If another user does something annoying I'll slap his wrist.  Oh wait.
That'd be me slapping myself.  Duh!

The default behaviour must be to allow all use that isn't disastrous.
Pam_console's premise is to restrict all use except that which is
enumerated.  That's dumb.

What purpose is served when a camera is plugged in to a USB port by
allowing access to one userid and disallowing access to another?

I'd like to get rid of this entire hare-brained mountain of confusion
and restriction and just allow unfettered use of all capabilities.

Any suggestions?


Comment 4 Harald Hoyer 2008-01-21 08:23:42 UTC
# yum info PolicyKit
Installed Packages
Name   : PolicyKit
Arch   : x86_64
Version: 0.6
Release: 1.fc8
Size   : 181 k
Repo   : installed
Summary: Toolkit for privilege control
Description:
PolicyKit is a toolkit for defining and handling the policy that
allows unprivileged processes to speak to privileged processes.

See also:
http://www.harald-hoyer.de/linux/console_acls_for_palm

Comment 5 Matthew Hannigan 2008-06-20 13:05:09 UTC
My Powershot A400 doesn't work in Fedora9 either in normal mode
or ptp mode for presumably the same reasons as this doesn't work in f8.

It worked in fc6, eventually in fc7 and now fails in f9.

The actual message is
   Error initializing camera: -114: OS
   error in camera communication

This camera is identified as
Canon Digital Camera idVendor=04a9, idProduct=30b7


Comment 6 Matthew Hannigan 2008-06-20 13:11:17 UTC
Hmm, Bug 443515 suggests that this might be
fixed with gphoto2 2.4.1.

(I just noticed that the gphoto2 is suffixed fc7;
is this right?!)



Comment 7 Jindrich Novy 2008-08-03 19:53:01 UTC
Hmm, gphoto2-2.4.2 should have fixed that since it contains many of Canon-related fixes. Could you please try with the rawhide gphoto2?

Comment 8 Bug Zapper 2008-11-26 09:27:57 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 9 Bug Zapper 2009-01-09 07:35:47 UTC
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.