Slack12, libgphoto2-2.4.0, Canon Powershot A95
 

Hi All,

I recently built Digikam 0.9.2, gphoto2-2.4.0, and libgphoto2-2.4.0 using slackbuilds from slackbuilds.org. Everthing works fine, but I can only access the camera as root. I have all users in the plugdev group but still no joy.

This is a bit frustrating as I had this working over several earlier versions of slack and libgphoto2 and had copied a functional camera.rules which I had been using for new installs. Apparently the syntax has changed and no matter what I seem to try, a normal user cannot access the camera.

Thanks in advance.

when you connect the camera... does HAL allow you to auto mount it as a normal user >?

Thanks for the reply.

I use KDE, so when the camera is connected as a normal user I get a pop-up that tells me a camera was detected and asks what I want to do with it. When I open Digikam (not given as a choice by the media pop-up by-the-way), the the camera can be added to the camera list in Digikam using the auto-scan procedure, and is detected as the A95 in PTP mode (previous versions of libgphoto2 also saw normal mode, but not 2.4.0) When I try to access the camera however, it fails. I would like to add, that any time I have had a permissions problem with a camera in the past, I was NOT able to add the camera to the camera list in digikam, even if auto-scan detected it.

As root, the camera is detected by KDE as well, but when the Media pop-up tells me a camera has been detected, opening the camera with Digikam is listed as an option, whereas a normal user is not given this as a choice.

Just a reminder that this camera cannot be loaded as a usb mass storage device. You must use libgphoto2.

Ohh, I am sorry , I thought it was mounted as a USB Mass storage device (most cameras are).

I think this implies the problem is in digikam. I think your normal user's KDE isn't properly configured to use digikam (rather it doesn't know that digikam is there). You might wanna play around in the KDE control centre , you could probably fix it somewhere there.


But as I said, I never used libgphoto so wouldn't know much.

No, digikam works fine. This is a usb permissions problem involving udev rules and libgphoto2 (maybe hal too). Just in case, I also tried gtkam and this application also failed to initialize the camera as a normal user despite correctly identifying the camera via auto-scan.

I'm currently re-reading the ghoto2 documents regarding usb permissions. The author indicates that a hal-fdi file needs to be edited or created. Maybe this is involved as hal also appears to be a new wrinkle here. I'm not really confident though as the examples are from FC6 and the author states from the top he's clueless regarding hal so he just copied and pasted the examples to his howto.

I'm also wondering if I need to something different because this is now a PTP camera with no option for normal mode any longer.

Sigh - too many variables.

Anyone successfully beat this combo into submission?

Slackware-12.0, udev-111, hal-0.9.5.1, libghoto-2.4.0, and gphoto-2.4.0?

I have here Slackware 12.0 running, gphoto2-2.4.0, libgphoto2-2.4.0, gtkam-0.1.14 and libexif-gtk-0.3.5 (hal and udev in your mentioned versions). I used the Slackbuilds from slackbuilds.org.

I have a Canon PowerShot A 60.

I added a rule to $HOME/.ivman/IvmanConfigActions.xml to open gtkam at the moment the camera is plugged in (I use fluxbox as windowmanager).

This works without any problems. I can copy, remove, add folders, pictures, movies from and onto the camera.

My user is in group "plugdev,audio,cdrom,video,wheel".

Fluxx.

Hm, I have a "Start digiKam" in the KDE popup window that appears when I plug in a camera. I am using my own set of packages for digiKam: http://www.slackware.com/~alien/slackbuilds/digikam/ (it's dependencies can be found there as well).

Eric

I don't believe this is a digiKam issue per se.

After reading the usb permissions howto from gphoto2 and looking at the referenced files on my install, I am beginning to suspect that the slackbuild script I used may not have worked as advertised.

I think I will look for another libgphoto2 build script to try and see if that helps at all.

My group ownership does not seem to be an issue and I'll spare you all the output of ldd on both digiKam and gtkam. All dependencies are met.

Steve

Well, I went the easy route and installed Alien Bob's packages for digiKam and libgphoto2 and unfortunately I am still unable to access the camera as a normal user. Root works great as allways.

So it seems I'm just not configuring udev properly.

I guess I'll keep googling for an answer.

Thanks.

Could you post your rules file? it might help us figure out your problem. Also, the libgphoto2 script from SBo was modified from the original to create a rules file for you (iirc), so that might have been your problem when using that script.

FYI, gphoto2 has not been a dependency of digiKam for quite some time. There is no reason to install it unless you plan on accessing your camera from the CLI.

MagicMan

This appears to be the udev rules problem which I have had

I found that adding the line

SYSFS{idVendor}=="04a9", SYSFS{idProduct}=="3058", GROUP="users"
to 10-udev.rules got it working for users as well as root.

Looking back over my old postings here what I did to get the SYSFS values was /usr/lib/libgphoto2/print-camera-list udev-rules > camera.rules
By examining the usbcam.usermap file I was able to identify the camera in camera.rules.

The udev rules generated by libgphoto2 *should* work properly. If they don't, then my first guess is that it's a problem with the rule generator itself.

Alternatively, if you're using a newer kernel than what Slackware 12 ships, then it's a good possibility that changes to the kernel's sysfs structure might have some effect, but I'm honestly not sure. I do know that my wife's camera (in PTP mode) worked just fine in a stock Slackware 12 installation with the libgphoto2 from SlackBuilds.org when I approved the script.

Just a comment about the digikam slackbuild at slackbuild.org and all the dependencies. I used them and my camera woks as normal user.

I got the impression that he was still using his old camera.rules file when he tried the new libgphoto2 from SBo and that might have been the source of the problem, conflicting rules files. He removed it though and installed using Eric's script and it still doesn't work. Its likely that the rules file he's currently using still needs minor tweaking but we wont know that until we see it.

Always glad to hear that kind of feedback :D

MagicMan

Hi Everyone and thanks for the replies. I had this thing called work today, but I wanted to reply and let you know I was still listening.

I am running a different (from slackware stock) kernel on both my computers - 2.6.22.5. Each computer has a different config tuned to the hardware. This may indeed be involved. One variable at a time please. ;)

I will post my 50-udev.rules if you think it might help. This is from my desktop and is more or less unchanged. I had been editing files on the laptop more.

Before I ran out of gas last night I was going to try to create a new 90-libgphoto2.rules file using /usr/bin/print-camera-list. Why not ;)

My 50-udev.rules file:

Yeah, work sucks. :-)

Well, before getting *too* involved, I'm going to request that you reproduce it on the stock generic kernel :-)

The 50-udev.rules file shouldn't have been altered by anything, so that isn't the issue.
I'm inclined to say that you should verify that the 90-libgphoto2.rules and hal fdi files installed by the package have the correct contents.

When I asked you to post your rules file, I actually meant your current camera rules file. I guess I wasn't specific enough, sorry.

MagicMan

hi. i want to try installing digikam in my slack 12.0 but im using fuse and ntfs 3g. do i still need HAL? plus, wat are the complete packages to be installed if i want to use digikam?

Well - I installed 2.6.21.5 smp generic with an initrd for ext3 and I can now access the camera as a normal user.

The question now is is the a case of a missing option or a missing initrd (per the discussion in the HAL sticky thread).

I will rebuild my 2.6.22.5 laptop kernel with the only change being ext3 as a module and the use of an initrd and let you know what I see.

Getting close - thanks!

It's a missing option (or options)
.
There's no "magic" in an initrd. Its only purpose is to provide the necessary drivers to access the root partition at boot. The initrd provides a small temporary root filesystem, the kernel loads the necessary module(s) from the initrd's filesystem, and then it uses either switch_root or pivot_root (sorry, I don't recall which one at the moment) to use the real root filesystem. At that point, the system continues on normally and the initrd is wholly and completely irrelevant.

And that would be my understanding as well. The initrd loads modules required at boot that would not be loaded early enough in the process otherwise.

The section I refer to in the HAL thread is the part where the / partition cannot be accessed by root nor by a user via the system:/media module if an initrd is not used. I can confirm that making no other change except to load ext3 as a module via an initrd.gz changed this behavior of the KDE system:/media module so that I can now access the root partition in this manner. (not that I cared one way or the other)

I did not bring my camera to work so that will need to wait. I did not expect much from an initrd to be honest, but it was an easy and quick way to remove a variable from the list.

I am not drawing any conclusions here, just making observations.

I can't post any configs at the moment (being at work), but any suggestions as to suspected omissions?

Thanks.

Well, not exactly. It contains modules that otherwise can't even be accessed. When the kernel is initially booted, if it doesn't have support for your root filesystem (and anything else, such as the chipset, etcetera) that it needs, it can't access the root filesystem. Since the kernel modules to access the root filesystem are *on* the root filesystem, well, that's bad. That's where the initrd comes in...

Yeah, I'm familiar with that thread, and that's what I thought you were referencing. It's not the presence of an initrd that resolves the system:/media problem, but sadly, I simply don't know what *is* resolving it. It's obviously some difference in the huge* versus generic* kernels, and while there aren't too many differences in the configs, it's quite frankly enough to dissuade me from trying too hard to track it down -- after all, there's a reason that the release notes and such advise to use one of the generic* kernels.
I suspect that some driver doesn't behave quite correctly when compiled statically into the kernel while behaving just fine as a module (there's some precedent for that - the iSCSI stuff comes to mind). On the other hand, I've seen reports of this problem in other distributions where it was somehow related to the lack of a /dev/root node (which is a symlink to the device holding the / filesystem), but I honestly don't see the connection there, so I can't even attempt to explain it, and I certainly don't understand why it would work with the generic* kernels (without /dev/root) but not in the huge* kernels (without /dev/root).

It might not be a config problem - instead, it could be a change in the way the kernel exports sysfs contents. I would think that the libgphoto2 folks would have acknowledged that though, but it's still worth some googling perhaps.

As for config options, the only thing that stands out at the moment is this: make sure you don't enable the CONFIG_SYSFS_DEPRECATED or something along those lines; there have been all sorts of problem reports on HAL with that enabled.

bash-3.1$ cat config | grep -i sysfs
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_SYSFS=y



Is this fine? Or should I disable sysfs too ?

NO, NO, don't do that. What you have is correct. :-)

If you disable sysfs, you wouldn't be able to use hal or udev at all.

That wasn't the issue here.

I did try a couple of changes, but none had the desired effect.
I went back to using the generic config as a base to build the kernel and everything worked as user.
Good news here is that the other packages seem to be doing everthing right script-wise. No need to edit udev rules.

I'll need to to take some time to try to figure what the offending option(s) are.
It's not immediately obvious to me. Maybe the USB drivers or related options?

Thanks for the help, it would have taken longer for me to look at the kernel for the answer.

I used this post to get my Canon S10 working in Slackware 12.0 with the Slackbuild.org versions of libgphoto2-2.4.0 and gtkam-0.1.1.4. I am running a stripped non-smp kernel. What proved to be the issue for me was enabling rc.scanluns. I do not know if this is an issue for ptp mode but may be for those using non-ptp drivers (? if assigned a LUN other than 0) in libgphoto2.

When I added OWNER="<user>" to 90-libgphoto.rules gtkam would find the camera but could not read the digital card. I recalled that rc.scanluns had something to do with reading usb devices
After chmod +x /etc/rc.d/rc.scanluns, removing "OWNER="<user>"from 90-libgphoto2.rules and rebooting gtkam worked fine as a user.