Bug 150985

Created attachment 111940 [details]
output of lsusb

Created attachment 111941 [details]
output of lshal

Created attachment 111942 [details]
/etc/fstab

Created attachment 111943 [details]
output of strace hald --daemon=no

Comment on attachment 111943 [details]
output of strace hald --daemon=no

root@ontap:~# service haldaemon stop
Stopping HAL daemon:					   [  OK  ]
root@ontap:~# hald --daemon=no
*** [DIE] osspec.c:osspec_init():328 : Unable to bind to netlink socket
root@ontap:~#  service haldaemon start
Starting HAL daemon:					   [  OK  ]
root@ontap:~#

Confirmed. The strange thing is that for me Nautilus windows (yes,
windows, one for each directory on the camera) are opened. I've told
gnome-volume-properties to not open Nautilus windows for anything...

Ignore that about Nautilus opening windows. It seems my wife got
confused and opened all those windows :-)

Btw, I just noticed that after plugging and unplugging my camera,
gnome-volume-manager was suddenly eating all available cpu time. Don't
know what it was using it for though...

Additional info: The high cpu consumption by gnome-volume-manager only happens
if the checkbox for starting program when camera is detected is checked.

I tried running gnome-volume-manager manually from the shell. When the camera
was connected I get the following, I hope it helps:

manager.c/794: New Device:
/org/freedesktop/Hal/devices/usb_device_4cb_112_Y_393_____020913WFC00001022379
manager.c/794: New Device:
/org/freedesktop/Hal/devices/usb_device_4cb_112_Y_393_____020913WFC00001022379_if0
libhal.c 1058 : wrong reply from hald.  Expecting an array.
libhal.c 1058 : wrong reply from hald.  Expecting an array.
manager.c/794: New Device:
/org/freedesktop/Hal/devices/usb_device_4cb_112_Y_393_____020913WFC00001022379_if0_scsi_host
manager.c/794: New Device:
/org/freedesktop/Hal/devices/usb_device_4cb_112_Y_393_____020913WFC00001022379_if0_scsi_host_scsi_device_lun0
manager.c/794: New Device: /org/freedesktop/Hal/devices/storage_model_USB_DRIVEUNIT
manager.c/794: New Device: /org/freedesktop/Hal/devices/volume_part1_size_65507840
manager.c/834: Changed: /dev/sda1
manager.c/771: Added: /dev/sda1
manager.c/919: Mounted: /org/freedesktop/Hal/devices/volume_part1_size_65507840
manager.c/312: Photos detected: /mnt/fujifilm/dcim

OK, comment 6, comment 7 and comment 8 Seems like a gnome-volume-manager bug to
me so please pursue that there. 

John, wrt. to the bug you posted, it seems that your camera is a USB Mass
Storage device (e.g. not mounted into the file system), right?

Correction from comment 9; I meant to say

John, wrt. to the bug you posted, it seems that your camera is a not USB Mass
Storage device (e.g. not mounted into the file system), right?

I'm not sure.  How can I tell?
I have no entry in /etc/fstab for it.

The problem still exists with:
 hal-0.5.0.cvs20050318-1
 nautilus-2.9.91-2
 kernel-2.6.11-1.1191_FC4
 gnome-volume-manager-1.1.3-3

Its a Canon PowerShot G3.  Running "lsusb -v" returns:

Bus 002 Device 004: ID 04a9:306e Canon, Inc.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass       255 Vendor Specific Subclass
  bDeviceProtocol       255 Vendor Specific Protocol
  bMaxPacketSize0        32
  idVendor           0x04a9 Canon, Inc.
  idProduct          0x306e
  bcdDevice            0.01
  iManufacturer           1 Canon Inc.
  iProduct                2 Canon Digital Camera
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               none
          Usage Type               Data
        wMaxPacketSize     0x0040  bytes 64 once
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               none
          Usage Type               Data
        wMaxPacketSize     0x0040  bytes 64 once
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               none
          Usage Type               Data
        wMaxPacketSize     0x0040  bytes 64 once
        bInterval              96
  Language IDs: (length=4)
     0409 English(US)

 

Thanks for the useful output in comment 11 - this shows that the camera is
indeed not an USB Mass Storage device. It's true this worked in hal 0.4.x in
FC3; for hal 0.5.x it needs some extra work (since we changed a few things) -
I'll leave this bug open until that is done. 

Who is it that needs help to fix this bug, and what do they need?  Its now 6
months later and still USB cameras don't work properly on Fedora.

Sorry, I didn't find this bug when searching, and so I posted a new bug
(#170223) this week instead. This stuff worked for me for a while, but now it
stopped working again. It seems this is a very problematic area....

Using hal-device-manager (very nice! why isn't in a fedora menu???)
I see my camera with:
   camera.access_menu string ptp
but gphoto2 only provides:
   /usr/share/hal/fdi/policy/20thirdparty/90-gphoto-camera-policy.fdi
which only matches:
   <match key="camera.access_method" string="libgphoto2">

The following patch adds support for ptp, and seems to fix my camera.

Created attachment 120983 [details]
fix permissions for ptp cameras

Sorry, that should have read:
    camera.access_method string ptp

Thanks for the patch.  I'll get it in soon so it goes out with test 1. 
Hopefully that covers the range of non-mass storage devices which need direct
access through proc.

This patch won't as it only applies to:
   <match key="info.capabilities" contains="camera">
but it does look like the underlying udev+hal mechanics are working
and there is now one example to help with fixing other devices.

Thanks John, closing as rawhide.