Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 131756 - libusb-0.1.12 breaks scanning as non-root
Summary: libusb-0.1.12 breaks scanning as non-root
Status: VERIFIED TEST-REQUEST
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: Alastair Tse (RETIRED)
URL:
Whiteboard:
Keywords:
: 149968 150463 (view as bug list)
Depends on: 150223 158626
Blocks: 148013
  Show dependency tree
 
Reported: 2006-04-29 23:12 UTC by Jim Mar
Modified: 2007-04-01 14:12 UTC (History)
23 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
usbcam (usbcam,1.26 KB, text/plain)
2006-10-22 13:10 UTC, Krzysztof Nowicki
Details
usbcam (usbcam,1.15 KB, text/plain)
2006-10-22 13:15 UTC, Krzysztof Nowicki
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jim Mar 2006-04-29 23:12:31 UTC
emerging libusb-0.1.12 causes the famous "can't scan as non-root" permissions problem. Reversion to libusb-0.1.11 fixes the problem.
Comment 1 Juergen Kaetzler 2006-05-01 01:02:06 UTC
Same problem here, not only for scanning, I can't access my digital camera either!

This is what I get with libusb-0.1.12 (as root):
hardcore ~ # sane-find-scanner 

found USB scanner (vendor=0x06b9 [ALCATEL], product=0x4061 [Speed Touch USB ]) at libusb:002:003
  # Your USB scanner was (probably) detected. It may or may not be supported by
  # SANE. Try scanimage -L and read the backend's manpage.

hardcore ~ # scanimage -L
device `plustek:libusb:002:004' is a Canon N670U/N676U/LiDE20 USB flatbed scanner

when I try to access my usb-scanner as a normal user:

tekknokaetzi@hardcore ~ $ sane-find-scanner

found USB scanner (vendor=0x04a9, product=0x220d, chip=LM983x?) at libusb:002:004
found USB scanner (vendor=0x06b9, product=0x4061) at libusb:002:003
  # Your USB scanner was (probably) detected. It may or may not be supported by
  # SANE. Try scanimage -L and read the backend's manpage.

tekknokaetzi@hardcore ~ $ scanimage -L

No scanners were identified. If you were expecting something different,
check that the scanner is plugged in, turned on and detected by the
sane-find-scanner tool (if appropriate). Please read the documentation
which came with this software (README, FAQ, manpages).

Same problem for my digital camera: it's recognised but I can't access it.

after reverting back to libusb-0.1.11 I can access my scanner and my digital camera as a normal user:

tekknokaetzi@hardcore ~ $ sane-find-scanner

found USB scanner (vendor=0x04a9 [Canon], product=0x220d [CanoScan], chip=LM9832/3) at libusb:002:005
  # Your USB scanner was (probably) detected. It may or may not be supported by
  # SANE. Try scanimage -L and read the backend's manpage.

tekknokaetzi@hardcore ~ $ scanimage -L
device `plustek:libusb:002:005' is a Canon N670U/N676U/LiDE20 USB flatbed scanner

emerge --info:
Portage 2.1_pre9-r5 (default-linux/x86/2005.0, gcc-4.0.3, glibc-2.3.6-r3, 2.6.16-beyond-git12 i686)
=================================================================
System uname: 2.6.16-beyond-git12 i686 Intel(R) Pentium(R) 4 CPU 1400MHz
Gentoo Base System version 1.12.0_pre18
ccache version 2.4 [enabled]
dev-lang/python:     2.4.2-r1
dev-util/ccache:     2.4-r1
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r2
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r5
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=pentium4 -mtune=pentium4 -msse -msse2 -pipe -O2 -fomit-frame-pointer -momit-leaf-frame-pointer -fno-ident -fforce-addr -falign-functions=4"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/env.d"
CXXFLAGS="-march=pentium4 -mtune=pentium4 -msse -msse2 -pipe -O2 -fomit-frame-pointer -momit-leaf-frame-pointer -fno-ident -fforce-addr -falign-functions=4 -fvisibility-inlines-hidden"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://gentoo.inode.at/source/ http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo"
LANG="de_DE@euro"
LC_ALL="de_DE@euro"
LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -s -Wl,--as-needed"
LINGUAS="de"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /usr/local/overlays/gentoo-de"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="x86 X acpi alsa arts atm avi bitmap-fonts cdr cli crypt cups divx4linux dlloader dri dvd encode ffmpeg foomaticdb gdbm gif gphoto2 gpm gtk gtk2 imlib ipv6 isdnlog joystick jpeg kde libg++ libwww mad mmx motif mp3 mpeg ncurses nls nptl nptlonly nsplugin nvidia ogg oggvorbis opengl oss pam pcre pdf pdflib perl pic png pppd python qt quicktime readline real reflection scanner sdl session spell spl sse sse2 ssl svga tcpd tiff truetype truetype-fonts type1-fonts usb vorbis win32codecs wmf xml2 xmms xorg xv zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux linguas_de userland_GNU video_cards_nv video_cards_nvidia video_cards_fbdev video_cards_vesa"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK
Comment 2 Jim Mar 2006-05-01 06:30:05 UTC
I did some debugging. It seems that the line

ret = ioctl(dev->fd, IOCTL_USB_SETCONFIG, &configuration);

in usb_set_configuration in linux.c returns a different error as non-root for libusb-0.1.12 and libusb-0.1.11. libusb-0.1.12 returns E_PERM.

Comment 3 Jim Mar 2006-05-01 21:39:37 UTC
OK, I found out why this is happening, but the answer is not pleasant. It turns out that libusb-0.1.11 is looking for usb devices at /proc/bus/usb while libusb-0.1.12 is looking at /dev/bus/usb.

All the documentation and hotplug scripts call for changing permissions at /proc/bus/usb.

One solution is to change all the documentation and hotplug scripts to change permissions at /dev/bus/usb instead.

I don't know the extent or consequences ot this change. Comments?
Comment 4 Jim Mar 2006-05-03 06:01:26 UTC
OK, here's how I fixed this problem. I added the file 10-scanner.rules to /etc/udev/rules.d consisting of the line:

BUS="usb", SYSFS{idVendor}="04b8", SYSFS{idProduct}="0818", PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", NAME="%c", MODE="0660", GROUP="scanner"


Comment 5 Jonathan Adamczewski 2006-06-11 19:15:43 UTC
Can confirm this bug with gphoto.

Changing perms on /dev/bus/usb/appropriate/file allows non-root access again.

Don't have a pretty, general solution.
Comment 6 Alastair Tse (RETIRED) gentoo-dev 2006-08-11 01:37:16 UTC
http://libusb.cvs.sourceforge.net/libusb/libusb/linux.c?r1=1.77&r2=1.78

this is the change that did it. which documentation says to change the permissions on /proc/bus/usb? on my machine both permissions are the same, no root write access, am I missing something?
Comment 7 Jim Mar 2006-08-11 08:00:16 UTC
(In reply to comment #6)
> http://libusb.cvs.sourceforge.net/libusb/libusb/linux.c?r1=1.77&r2=1.78
> 
> this is the change that did it. which documentation says to change the
> permissions on /proc/bus/usb? on my machine both permissions are the same, no
> root write access, am I missing something?
> 

The code changes that you reference seem to be related to determining whether usb is found or not, either /proc/bus/usb or /dev/bus/usb. The change that seems to cause the problem is code determining the permissions of the usb devices, which have changed from /proc/bus/usb to /dev/bus/usb. The permissions are now checked on /dev/bus/usb. On your machine, are you looking at /proc/bus/usb, /dev/bus/usb, or both?

The workaround here, and in the forums, is to write a special udev rule to create the /dev/bus/usb devices with the proper permissions for the new usb device. This is unsatisfactory as it is not general and depends on writing special udev rules for each specific usb device.
Comment 8 Alastair Tse (RETIRED) gentoo-dev 2006-08-11 10:14:32 UTC
I agree that the udev rules is not a good solution. I'll see if I can get upstream to look at this.
Comment 9 Peter 2006-09-24 15:21:45 UTC
i got the same problem, downgrading to libsusb-0.1.11 works fine for me, on 0.1.12 i couldn' acces even my camera had to do udev rule but this is not ok
Comment 10 Alastair Tse (RETIRED) gentoo-dev 2006-09-24 16:58:15 UTC
vapier, you might not want to mark libusb-0.1.12 stable for sh, s390 and arm because of this bug.
Comment 11 SpanKY gentoo-dev 2006-09-24 20:54:42 UTC
isnt udev broken ?  shouldnt this line:

SUBSYSTEM=="usb_device", PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", NAME="%c", MODE="0644"

read MODE="0664" and GROUP="usb"
Comment 12 Horst Prote 2006-10-02 06:07:23 UTC
The same error here. But after

  echo "=media-gfx/sane-backends-1.0.18-r2 ~x86" >> /etc/portage/package.keywords
  emerge -pu sane-backends

  These are the packages that would be merged, in order:

  Calculating dependencies... done!
  [ebuild     U ] media-gfx/sane-backends-1.0.18-r2 [1.0.17]
  emerge -u sane-backends
  etc-update
  reboot

scanning as non-root with libusb-0.1.12 works again for me.
(According to Bug 148608 sane-backends-1.0.18-r2 should become x86 stable soon.)
Comment 13 SpanKY gentoo-dev 2006-10-02 06:45:55 UTC
gregkh: check out Comment #11
Comment 14 Antti Mäkelä 2006-10-03 02:55:26 UTC
Also encountered this issue with gphoto and a Canon camera. USB permissions under /proc/bus/usb are correct, but apparently libusb checks them at /dev/bus/usb.

Can 0.1.12 be marked back to testing for time being, until solution is found, perhaps upstream?
Comment 15 Alastair Tse (RETIRED) gentoo-dev 2006-10-03 11:32:45 UTC
*** Bug 149968 has been marked as a duplicate of this bug. ***
Comment 16 Alastair Tse (RETIRED) gentoo-dev 2006-10-03 11:34:18 UTC
arch teams, can you please not mark 0.1.12 stable for your respective architectures. this problem needs to be solved otherwise your users are going to complain.
Comment 17 Wormo (RETIRED) gentoo-dev 2006-10-03 15:57:08 UTC
libusb-0.1.12 back to ~ppc for now; has upstream given any feedback on this issue yet?
Comment 18 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2006-10-03 16:50:35 UTC
sane needs udev rules written. they aren't hard to do.

the move to /dev/bus/usb was reasonably announced by upstream, and other packages have responded in kind. I've been trying to get nut-2.0.4* stable, because it finally supports a lot of newer USB UPSes. It ships with this udev rule file (/etc/udev/rules.d/70-nut-usbups.rules), that sane will need to implement something like for libusb:

# udev rules for the NUT USB drivers
SUBSYSTEM!="usb_device", ACTION!="add", GOTO="nut-usbups_rules_end"
# MGE UPS SYSTEMS - usbhid-ups
SYSFS{idVendor}=="0463", SYSFS{idProduct}=="ffff", MODE="660", GROUP="nut"
SYSFS{idVendor}=="0463", SYSFS{idProduct}=="0001", MODE="660", GROUP="nut"
# APC - usbhid-ups
SYSFS{idVendor}=="051d", SYSFS{idProduct}=="0002", MODE="660", GROUP="nut"
# Powerware - bcmxcp_usb
SYSFS{idVendor}=="0592", SYSFS{idProduct}=="0002", MODE="660", GROUP="nut"
# Tripp Lite - tripplite_usb
SYSFS{idVendor}=="09ae", SYSFS{idProduct}=="0001", MODE="660", GROUP="nut"
LABEL="nut-usbups_rules_end"

Sane should have it MUCH easier than NUT however, as IIRC all scanners should show up with a bInterfaceClass of USB_CLASS_STILL_IMAGE (6), which means you can cover every scanner with a single udev rule.

If two or three people with USB scanners could attach tarballs of their /sys directory, I'll gladly whip up some udev rules for you, so that libusb can move forward, instead of backwards.
Comment 19 Antti Mäkelä 2006-10-03 23:13:06 UTC
Apparently gphoto 2.2.0 also does the UDEV rules:

http://www.gphoto.org/news/

So if you want to move this to stable, gphoto 2.2 should be stabilized at the same time.
Comment 20 Decibels 2006-10-04 23:13:09 UTC
Could libusb-0.1.12 be marked back ~amd64 also. This bit me today also. 

The only reason the scanner worked is because had a local udev rule in there from long time ago. 

What about what SpanKY said in #11? That is already there and shouldn't it be written that way from the getgo? :

SUBSYSTEM=="usb_device", PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf
bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", NAME="%c", MODE="0644"

read MODE="0664" and GROUP="usb"
Comment 21 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2006-10-04 23:34:06 UTC
decibelshelp: changing that rule per spanky's request is one fix. the alternative fix like nut uses would end up with the similar result.

spanky: maybe open a new bug to gregkh to get it fixed quicker?
Comment 22 Jean-Marc Beaune 2006-10-05 03:35:53 UTC
Hi,

I had the same problem and found on forums another work around :

# echo "export USB_DEVFS_PATH=/proc/bus/usb" >> ~/.bash_profile
Comment 23 Greg Kroah-Hartman (RETIRED) gentoo-dev 2006-10-05 13:29:19 UTC
Don't use that environment variable, just fix the packages to do it properly.
Comment 24 Daniel Gryniewicz (RETIRED) gentoo-dev 2006-10-05 14:13:47 UTC
Okay, back to ~amd64.  (sorry, got lost in the shuffle)  Add us back when you want it stable again...
Comment 25 Jakub Moc (RETIRED) gentoo-dev 2006-10-08 10:20:58 UTC
*** Bug 150463 has been marked as a duplicate of this bug. ***
Comment 26 onip 2006-10-09 10:32:43 UTC
(In reply to comment #9)
> i got the same problem, downgrading to libsusb-0.1.11 works fine for me, on
> 0.1.12 i couldn' acces even my camera had to do udev rule but this is not ok
> 

Downgrading didn't help (x86). I'm still not able to acces my ZenExtra as normal user. I did a revdep-rebuild too.

Any suggestion?
Comment 27 Ernst Bachmann 2006-10-12 07:56:31 UTC
What do the different upstreams (kernel/udev/libusb/lsb) say about this?

seems /proc/bus/usb (and usbfs) is now not longer needed, as udev can provide all of its functions from userspace, and /dev would be a more suitable namespace for usb device nodes anyways.

If usbfs really is deprecated/scheduled for removal, we should start fixing the udev rules now instead of waiting till a new kernel rev. breaks stuff.

just my 2
Comment 28 Ernst Bachmann 2006-10-12 07:56:31 UTC
What do the different upstreams (kernel/udev/libusb/lsb) say about this?

seems /proc/bus/usb (and usbfs) is now not longer needed, as udev can provide all of its functions from userspace, and /dev would be a more suitable namespace for usb device nodes anyways.

If usbfs really is deprecated/scheduled for removal, we should start fixing the udev rules now instead of waiting till a new kernel rev. breaks stuff.

just my 2¢,
/Ernst
Comment 29 Kelly Price 2006-10-15 10:19:27 UTC
Strange.  I have both sane-backends, gphoto2-2.2.0, and libusb-0.1.12 on amd64, and I can find my scanner as non-root.

Of course, the scanner in /dev/bus/usb/xxx/yyy is chgrp'ed "scanner" and the user I use (tygris) is part of the scanner group, so I don't have a permissions problem.

Someone double-check that:  Locate your scanner, where it's plugged in as root, and then ls -l the device in /dev/bus/usb to see if it's chgrp'ed "scanner".  Then check to see if the non-root user is in the "scanner" group in /etc/group.
Comment 30 Antti Mäkelä 2006-10-15 13:07:45 UTC
(In reply to comment #28)
> Strange.  I have both sane-backends, gphoto2-2.2.0, and libusb-0.1.12 on amd64,
> and I can find my scanner as non-root.

  That's because gphoto 2.2.0 has been made to work with the udev stuff - like I said earlier - it should have been marked stable at the same time as libusb-0.1.12.
Comment 31 Decibels 2006-10-15 13:17:27 UTC
(In reply to comment #28)
> Someone double-check that:  Locate your scanner, where it's plugged in as root,
> and then ls -l the device in /dev/bus/usb to see if it's chgrp'ed "scanner". 
> Then check to see if the non-root user is in the "scanner" group in /etc/group.
> 
Mine does:
/dev/bus/usb/002:
total 0
crw-r--r-- 1 root root    189, 128 Oct 15 01:28 001
crw-rw---- 1 root scanner 189, 133 Oct 15 15:10 006

and non-root user is in the scanner group

But that is only because I have a rule for the scanner. Had to write a rule a long time back to get it working. Wasn't the case with my camera though, before the libusb change it worked without a rule using gphoto2.

You sure you don't have a rule for the scanner that is making this work? 
Comment 32 Mike 2006-10-16 10:54:28 UTC
(In reply to comment #29)
> That's because gphoto 2.2.0 has been made to work with the udev stuff

Hm, i have gphoto 2.2.0 and nevertheless i had to manually create an udev rule so the usb device for my camera is created with the right group.. (it defaults to being owned by group root)
Comment 33 Antti Mäkelä 2006-10-16 13:05:33 UTC
(In reply to comment #31)
> (In reply to comment #29)
> > That's because gphoto 2.2.0 has been made to work with the udev stuff
> 
> Hm, i have gphoto 2.2.0 and nevertheless i had to manually create an udev rule
> so the usb device for my camera is created with the right group.. (it defaults
> to being owned by group root)
> 

Ah, then the package maintainer for gphoto hasnt added the stuff referred to in http://www.gphoto.org/news/


Build system (packagers beware!)

    * You should generate HAL FDI, linux-hotplug usb.usermap, and udev rules now via our program:

       	  ${libdir}/print-camera-list (hal-fdi|usb-usermap|udev-rules)
This obsoletes print-usb-usermap and print-udev-rules.
The hal FDI file should be put into:

	/usr/share/hal/fdi/information/10freedesktop/10-camera-libgphoto2.fdi

...so yes, udev rules need to be created but gphoto has the capability to do it automatically in 2.2.0. If the gphoto ebuild does not do it, I think a new bug should be filed.
Comment 34 Antti Mäkelä 2006-10-16 13:07:04 UTC
BTW, did you update libgphoto as well when you tested the 2.2?
Comment 35 Mike 2006-10-16 13:50:52 UTC
(In reply to comment #33)
> BTW, did you update libgphoto as well when you tested the 2.2?

Yes, it's a dependency.

Well, i did some further research now.
the udev rules from libgphoto (i've manually added them) just call the /etc/hotplug/usb/usbcam script, however that is already called from another source, so gentoo already had the correct rules i guess.
The usbcam script changes the group of $DEVICE to plugdev - however, $DEVICE is always /proc/bus/usb/..., never /dev/bus/usb/...
Comment 36 Krzysztof Nowicki 2006-10-22 13:10:07 UTC
Created attachment 100235 [details]
usbcam

> 
> Well, i did some further research now.
> the udev rules from libgphoto (i've manually added them) just call the
> /etc/hotplug/usb/usbcam script, however that is already called from another
> source, so gentoo already had the correct rules i guess.
> The usbcam script changes the group of $DEVICE to plugdev - however, $DEVICE is
> always /proc/bus/usb/..., never /dev/bus/usb/...
> 

The script is called, but there is something missing. When it's called from the hotplug agent, $DEVICE is set to /proc/bus/usb...., but when called from udev the device path resides in $DEVNAME.
This updated /etc/hotplug/usb/usbcam script does the job.
Comment 37 Krzysztof Nowicki 2006-10-22 13:15:45 UTC
Created attachment 100236 [details]
usbcam

Removed some debug stuff I accidentally left behind.
Comment 38 Patrick Lorazo 2006-10-28 16:15:54 UTC
(In reply to comment #26)
> (In reply to comment #9)
> > i got the same problem, downgrading to libsusb-0.1.11 works fine for me, on
> > 0.1.12 i couldn' acces even my camera had to do udev rule but this is not ok
> > 
> 
> Downgrading didn't help (x86). I'm still not able to acces my ZenExtra as
> normal user. I did a revdep-rebuild too.
> 
> Any suggestion?
> 

Hello,

I confirm: downgrading to libusb-0.1.11 (or even libusb-0.1.10a) also did NOT fix the problem (x86). However, setting "USB_DEVFS_PATH=/proc/bus/usb" does provide a temporary solution.
Comment 39 Mike 2006-10-29 06:09:18 UTC
(In reply to comment #36)
> Created an attachment (id=100236) [edit]
> usbcam

I can confirm that this works, together with gphotos udev rules which you get by doing:

/usr/lib/libgphoto2/print-camera-list udev-rules > /etc/udev/rules.d/libgphoto2.rules
Comment 40 Emmanuel Favre_Nicolin 2006-10-31 18:45:04 UTC
I have libusb-0.1.12  installed and can scan with my HP 1410 as normal user. Looks like I cannot reproduce the problem here.
Comment 41 Constantine 2006-11-01 00:58:40 UTC
(In reply to comment #0)
> emerging libusb-0.1.12 causes the famous "can't scan as non-root" permissions
> problem. Reversion to libusb-0.1.11 fixes the problem.

Running amd64, libusb-0.1.11, libgphoto2-2.1.6-r1, gphoto2-2.1.6 => non-root user can NOT access a digital camera whereas root can.

Entries in /proc/bus/usb are 664 root:plugdev
Entries in /dev/bus/usb are 664 root:root

chmod'ing the /dev/bus/usb to 666 gives access, presumably changing the group to plugdev would do the same.

I don't really know how to interpret the 50-udev.rules file but there is only one entry for usb_devices that I can see.
Comment 42 Patrick Lorazo 2006-11-01 09:36:28 UTC
(In reply to comment #39)
> I have libusb-0.1.12  installed and can scan with my HP 1410 as normal user.
> Looks like I cannot reproduce the problem here.
> 
With libusb-0.1.12 (x86), I can as well scan with my HP PSC 1210. However, I cannot access my digital camera (unless I become root).
Comment 43 Christian Weiske 2006-11-02 12:21:47 UTC
I do have the same problem: not being able to access the digital camera via gphoto2. I did have libusb-0.1.12 installed, but downgrading to 0.1.11 doesn't help. Changing permissions of /dev/bus/usb/ did actually help, so it seems to me as if libusb-0.1.11 does have the same problem.
Comment 44 Christian Weiske 2006-11-02 12:32:55 UTC
Ok, it also doesn't change when going back to 0.1.10a or 0.1.8 - so the root of the problem must be something different.
Comment 45 Michael 2006-11-04 21:25:53 UTC
(In reply to comment #42)
> I do have the same problem: not being able to access the digital camera via
> gphoto2. I did have libusb-0.1.12 installed, but downgrading to 0.1.11 doesn't
> help. Changing permissions of /dev/bus/usb/ did actually help, so it seems to
> me as if libusb-0.1.11 does have the same problem.
> 

Or the problem lies at least partly elsewhere.  Using either libusb 0.1.12 or 0.1.11, I can only access my camera as non-root with stable udev and a line in 10-local.rules for my camera.  Until recently was able to do so without the local rule and using udev 096-r1.
Comment 46 Patrick Lorazo 2006-12-24 05:51:01 UTC
The problem appears to be fixed since upgrade to gphoto2-2.2.0 and libgphoto2-2.2.1-r1. I can now fully access my digital camera (Nikon Coolpix 4600) as a regular user.
Comment 47 Niko Sams 2006-12-28 07:50:38 UTC
libgphoto2-2.2.1-r1 fixed the problem for mee to. (Canon Digital Ixus 55)
Comment 48 Jakub Moc (RETIRED) gentoo-dev 2007-01-15 10:56:06 UTC
So... everyone having the problem test w/ libgphoto2-2.2.1-r1 and report back please...
Comment 49 Christian Weiske 2007-01-15 14:18:23 UTC
/me still thinks udev is broken. I needed to change the usb_device rule in 50-udev.rules as Spanky suggested it in comment #11
Comment 50 Decibels 2007-01-15 20:51:54 UTC
The only problem I'm having with libgphoto2-2.2.1-r1 is the rules: get whole bunch of these during gentoo part of bootup: udevd[1094]: add_to_rules: unknown key 'ATTRS{idVendor}', in 'ATTRS{idVendor}'

Was helping out someone else getting this and they had this version. I upgraded and got it also. Can't remember order of things right now, but downgraded back to orig and still got it (perhaps orphaned udev rule file) and then removed 99-libgphoto2.rules file and error messages gone. Camera still worked, didn't need rules.

Was just thinking. I don't need a rule for my camera, perhaps this error is because don't have a rule?? If I don't have to have a rule for my camera I don't think udev or libgphoto2 should be forcing me to make one just so it doesn't produce those errors. Camera worked with or without the error messages anyway. 

Otherwise, camera works with that version of libgphoto2, but 2 boxes I know of get that output during boot with it. But right now haven't tested downgrading again after deleting the udev rule file to see if it puts one there or leaves an orphaned file. 

Ice storm of the centry hit us and have been without power for 2 1/2 days, will test out later. 
Comment 51 Brian Tarricone 2007-01-21 03:08:16 UTC
I'm having the same problem, and spent several hours searching the forums and other sources for a solution.  The USB_DEFVS_PATH env var works, but as mentioned here, isn't ideal.  This udev rule works for me:

SUBSYSTEM=="usb_device", DRIVER!="usbhid", DRIVER!="hub", DRIVER!="hci_usb", PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", NAME="%c", GROUP="plugdev", MODE="0664"

I put it in /etc/udev/rules.d/10-local.rules.  The idea here is that it doesn't set change the permissions on things like mice, keyboards, the USB hub itself, and (in my case) the hci_usb Bluetooth device.  It's probably not security-conscious enough for everyone, but it lets me have access to any camera plugged in, not just particular models.  Other libusb-based devices should work just as well.

Since the original rule is still in 50-udev.rules, other devices will get the default permissions.
Comment 52 nixnut (RETIRED) gentoo-dev 2007-03-02 20:01:37 UTC
Removing ppc from. Feel free to add us back if something ppc specific needs to be done.
Comment 53 nixnut (RETIRED) gentoo-dev 2007-03-02 20:58:27 UTC
really removing ppc now :/
sorry for the bugspam
Comment 54 Jakub Moc (RETIRED) gentoo-dev 2007-03-16 12:21:29 UTC
Reopen if you can reproduce with >=udev-104-r12; make sure you have *no* stale/orphaned files in /etc/udev/rules.d, that you've emerged udev with --noconfmem, that you've run etc-update or dispatch-conf after the upgrade and merged all the updated properly and rebooted the box after that.
Comment 55 Jim Mar 2007-03-18 17:59:30 UTC
Works fine for me now!
Comment 56 John Altstadt 2007-04-01 14:12:44 UTC
(Spring cleaning.)

This works for me too.