could it be that gtkam doesn't use libusb?

No, gthumb and f-spot suffer from the same problem.
The problem is that the product and vendor ID of that camera does not exist on the /etc/udev/rules/gphoto.rules file. However the system and HAL *recognizes* that this device is a camera and automatically fires up gThumb upon connection. And yet, just because the product ID is not on gphoto.rules file, it won't give my users access to the hardware, even if all are part of the camera group. If I manually add the product/vendor IDs on that file, then it works. But this is hardly intuitive.

This is a clash of bad design between HAL and gphoto IMHO. HAL wants to give access, gphoto doesn't.

well gphoto probably doesn't know all vendors and camera types, so there you need to do it by hand.

Tobias, you don't understand. When I connect the camera, gthumb COMES UP automatically. The system (HAL) RECOGNIZES that this is a PTP camera. It recognizes it as fully compatible. And then, because it loads apps that use gphoto instead of HAL to connect to the camera, it stops working spitting access problems.

This is a lot like Windows telling you that a new 512 MB USB got connected, and then Explorer comes up and tells you that it can't read or write to it. This behavior is a BUG.

Please ALTER gphoto to play by more modern rules (no, there are no security concerns for cameras IMHO), OR, don't let HAL come up like a little fart saying that there's a new camera connected. This behavior currently, is wrong. It gives a false hope to the user.

Things should JUST WORK.

What is exactly the thing that gphoto does? Does it change permissions in /proc? Does it change device names? If it's in /proc, I guess gphoto is the only one that can handle it. If it's in /dev, we need udev rules. HAL can detect the camera, so udev knows it's a camera too then.

I don't know what gphoto does. I think it just restricts all cameras to root if it doesn't recognize their IDs. I think it's a udev rule that's required to tell it to stop being paranoid if it doesn't recognize the specific camera.

There's more than just hal and udev and gphoto. What happens is this:
- hal doesn't know shit about any camera, it just fires up a gphoto application for any camera it thinks it is a camera (actually gnome-volume-manager does this based on hal policy)
- gphoto 2.1.x doesn't support your camera officially, so the udev rules file doesn't contain a rule to set permission on your camera

The solution:
- update to libgphoto2 2.2.1, which should support your camera
- make libgphoto2 generate fdi files so hal knows which camera is supported and which one isn't
- make libgphoto2 generate udev rules with the tool that comes with it, not some shitty bash script we invented ourselves to convert a hotplug map.

With this new setup, gnome-volume-manager will only fire up the photo program when you plugin a camera that is supported by gphoto2. This also means that we should be a bit quicker on libgphoto2 updates and that we should receive bugs when people find cameras that aren't supported by gphoto2, but which work with a driver supplied with libgphoto2.

Could you try the new libgphoto2-2.2.1-1 package and see if it solves your problem?

I don't know, as I have added the product IDs by hand already in the udev folder, so I don't experience the problem anymore. I will have to get a new camera to test your change...

The udev rules have been overwritten AFAIK, so now it should include your camera by default. AFAIK you had a kodak camera, the latest libgphoto2 release includes quite some new kodak cameras.

Indeed. But I am not sure if the actual problem is fixed. In the future I might hit the problem again if the camera is not yet recognized by libgphoto.

The problem is that we can't really identify all cameras without a list. There's no thing in sysfs that says a certain device is a camera which could use a certain driver included in libgphoto2. We should just keep libgphoto2 up2date and add new cameras when these things appear. Other distributions utilize the same setup as we do, but instead of letting udev set permissions, they let hal do the permission settings.
At this moment, the only thing that hal does is know about the cameras in a .fdi file and only firing up gthumb when the camera is known to gphoto.

My point is, that when I plug a PTP-compatible camera on Windows, it just works (no need for a special driver). I expect the same from Linux, with the product IDs in place or without. Linux DOES have the ability to do the same, it's just that gphoto doesn't enable it for all users. And honestly, that's just paranoia on libgphoto's part. There shouldn't be any list of product IDs in the first place on the udev folder. Gphoto/hal/whoever, must detect that this is some sort of camera (they already do), and enable PTP for that camera to all users without asking the user to sacrifice a goat or start begging their admin to add the product IDs.

Could you provide me with information from lshal or hal-device-manager for your camera? If there's some generic attribute in the properties, I could try to make up generic udev rules that capture more than the "supported" cameras.

I will do that tonight, thanks.

lshal with no udev rules attached (i temporarily removed the gphoto.rules when i ran it).

Also, I upgraded to the new libghoto2, and your latest version still does NOT support my cameras. As a user I could not import pictures, same problem as with the previous version. They told me that these new product IDs are on the trunk of libgphoto2 that's not released yet. So, I had to manually add these on my own gphoto.rules file for 3 of our 9 cameras:

# Kodak P850
SYSFS{idVendor}=="040a", SYSFS{idProduct}=="0592", GROUP="camera"
# Canon A700 (Canon, Inc.)
SYSFS{idVendor}=="04a9", SYSFS{idProduct}=="3117", GROUP="camera"
# Kodak V550 (Kodak Co.)
SYSFS{idVendor}=="040a", SYSFS{idProduct}=="058f", GROUP="camera"

But of course, the point is for this to work out of the box... ;)

Hmm, looks like I got it: info.capabilities = {'camera', 'camera'} (string list)

This is the property that should make difference between regular USB devices and cameras. I'm not good at writing udev rules, but I guess some of us will come up with a generic camera rule then.

Perfect, thanks!

Assuming you plug the camera into the same port as you did when running lshal, could you run "udevinfo -a -p /sys/devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.0" and attach the results here? It looks like hal makes up the camera property from interface class, interface subclass and protocol.

Actually the above command does not work (even when I plug it on the same usb port), but after some fiddling, i got the following when running this: udevinfo -a -p /sys/devices/pci0000\:00/0000\:00\:1d.1/usb3/3-1/3-1\:1.0

SYSFS{bInterfaceSubClass}=="01"
SYSFS{bInterfaceClass}=="06"
SYSFS{bNumEndpoints}=="03"
SYSFS{bAlternateSetting}==" 0"
SYSFS{bInterfaceNumber}=="00"

looking at parent device '/devices/pci0000:00/0000:00:1d.1/usb3/3-1':
ID=="3-1"
BUS=="usb"
DRIVER=="usb"
SYSFS{configuration}==""
SYSFS{serial}=="CYEV539J6031"
SYSFS{product}=="KODAK EasyShare P850 Zoom Digital Camera"
SYSFS{manufacturer}=="Eastman Kodak Company"
SYSFS{maxchild}=="0"
SYSFS{version}==" 2.00"
SYSFS{devnum}=="3"
SYSFS{speed}=="12"
SYSFS{bMaxPacketSize0}=="8"
SYSFS{bNumConfigurations}=="1"
SYSFS{bDeviceProtocol}=="00"
SYSFS{bDeviceSubClass}=="00"
SYSFS{bDeviceClass}=="00"
SYSFS{bcdDevice}=="0100"
SYSFS{idProduct}=="0592"
SYSFS{idVendor}=="040a"
SYSFS{bMaxPower}==" 0mA"
SYSFS{bmAttributes}=="c0"
SYSFS{bConfigurationValue}=="1"
SYSFS{bNumInterfaces}==" 1"

looking at parent device '/devices/pci0000:00/0000:00:1d.1/usb3':
ID=="usb3"
BUS=="usb"
DRIVER=="usb"
SYSFS{configuration}==""
SYSFS{serial}=="0000:00:1d.1"
SYSFS{product}=="UHCI Host Controller"
SYSFS{manufacturer}=="Linux 2.6.17-ARCH uhci_hcd"
SYSFS{maxchild}=="2"
SYSFS{version}==" 1.10"
SYSFS{devnum}=="1"
SYSFS{speed}=="12"
SYSFS{bMaxPacketSize0}=="64"
SYSFS{bNumConfigurations}=="1"
SYSFS{bDeviceProtocol}=="00"
SYSFS{bDeviceSubClass}=="00"
SYSFS{bDeviceClass}=="09"
SYSFS{bcdDevice}=="0206"
SYSFS{idProduct}=="0000"
SYSFS{idVendor}=="0000"
SYSFS{bMaxPower}==" 0mA"
SYSFS{bmAttributes}=="e0"
SYSFS{bConfigurationValue}=="1"
SYSFS{bNumInterfaces}==" 1"

looking at parent device '/devices/pci0000:00/0000:00:1d.1':
ID=="0000:00:1d.1"
BUS=="pci"
DRIVER=="uhci_hcd"
SYSFS{modalias}=="pci:v00008086d000024C4sv00001584sd00009011bc0Csc03i00"
SYSFS{local_cpus}=="f"
SYSFS{irq}=="20"
SYSFS{class}=="0x0c0300"
SYSFS{subsystem_device}=="0x9011"
SYSFS{subsystem_vendor}=="0x1584"
SYSFS{device}=="0x24c4"
SYSFS{vendor}=="0x8086"

looking at parent device '/devices/pci0000:00':
ID=="pci0000:00"
BUS==""
DRIVER==""