SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
Distribution: Slackware 12 Kernel 2.6.24 - probably upgraded by now
Posts: 1,054
Rep:
Ohh, I am sorry , I thought it was mounted as a USB Mass storage device (most cameras are).
Quote:
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.
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.
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".
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).
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.
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.
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.
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.
The udev rules generated by libgphoto2 *should* work properly.
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.
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.
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
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.