udev-rule for PTP class detection broken

Bug #67532 reported by Henrik Binggl
164
This bug affects 2 people
Affects Status Importance Assigned to Milestone
libgphoto2 (Ubuntu)
Fix Released
Medium
Martin Pitt
Edgy
Won't Fix
High
Unassigned

Bug Description

host:
   Ubuntu 6.10
   Linux aragorn 2.6.17-10-generic #2 SMP

camera:
    Kodak EasyShare C530

problem:
    When camera is pluged in, error message is displayed. As
    usual, camera works with WindowsXP.

details:
    error-message:
    >An error occurred in the io-library ('Could not claim the USB
    >device'): Could not claim interface 0 (Operation not
    >permitted). Make sure no other program or kernel module
    >(such as sdc2xx, stv680, spca50x) is using the device and
    >you have read/write access to the device.

    cat /var/log/messages
    >Oct 22 12:22:23 aragorn kernel: [17184719.172000] usb 1-2:
    >new full speed USB device using uhci_hcd and address 2
    >Oct 22 12:22:24 aragorn kernel: [17184719.396000] usb 1-2:
    >configuration #1 chosen from 1 choice

how to reproduce:
    Every time I plug in the camera.

other usb hardware:
    usb-stick, mouse, joystick work

Related branches

Revision history for this message
Henrik Binggl (henrik-binggl) wrote :
Revision history for this message
Henrik Binggl (henrik-binggl) wrote :

solution found:

http://ubuntuforums.org/showthread.php?t=286730&highlight=kodak

enter the following line in '/etc/udev/rules.d/45-libgphoto2.rules'

SYSFS{idVendor}=="040a", SYSFS{idProduct}=="059a", MODE="0660", GROUP="plugdev"

Martin Pitt (pitti)
Changed in libgphoto2:
assignee: nobody → pitti
importance: Undecided → Medium
status: Unconfirmed → In Progress
Revision history for this message
Marcus Meissner (meissner) wrote : Re: missing udev-rule for Kodak EasyShare C530

Please use this line instead to fix _all_ PTP cameras:

ENV{INTERFACE}=="6/1/1", MODE="0660", GROUP="plugdev"

This should be worth an update.

Ciao, Marcus

Revision history for this message
Daniel James (daniel-netbreeze) wrote :

Just for reference, I have a Kodak P850. This is how it identifies itself:

Bus 003 Device 003: ID 040a:0592 Kodak Co.

I also needed to add rules to my udev rules.d. Note that I am running Edgy, this really need to be there by default.. Perhaps there should be a rule that just has the vendor id... There seem to be a lot of products missing at the moment..

Revision history for this message
Hubert Figuiere (hub) wrote :

Daniel,

the rule for the device class as indicated by Marcus should be enough for all PTP camera.

BTW P850 is supported in 2.3.0.

Revision history for this message
Daniel James (daniel-netbreeze) wrote :

Thanks for the info Hubert.

I just updated my udev rules and removed the rule specific to my camera. Then I added the INTERFACE rule was mentioned by Marcus. I restarted udev and plugged in my camera, this was the result:

An error occurred in the io-library ('Could not claim the USB device'): Could not claim interface 0 (Operation not permitted). Make sure no other program or kernel module (such as sdc2xx, stv680, spca50x) is using the device and you have read/write access to the device.

It appears that my camera is not using that interface...

Revision history for this message
thm (thomas-maier) wrote :

Same here with a Canon EOS 400D (Digital Rebel). I tried the general rule

ENV{INTERFACE}=="6/1/1", MODE="0660", GROUP="plugdev"

first. It did not work. I added

SYSFS{idVendor}=="04a9", SYSFS{idProduct}=="3110", MODE="0660", GROUP="plugdev"

Now it works. Thanks for the workaround.

Revision history for this message
Marcus Meissner (meissner) wrote :

unfortunately the ENV{INTERFACE} hack does not work, since iut happens not
in the device creation event.

I am using a check_ptp_camera helper script again in libgphoto2 2.3.1 (to be released)

Revision history for this message
Hubert Figuiere (hub) wrote : Re: [Bug 67532] Re: udev-rule for PTP class detection broken

thm wrote:
> Same here with a Canon EOS 400D (Digital Rebel). I tried the general
> rule

400D is Digital Rebel XTi. Not Digital Rebel.

Hub

Revision history for this message
Martin Pitt (pitti) wrote :

 libgphoto2 (2.3.0-0ubuntu1) feisty; urgency=low
 .
   * New upstream version 2.3.0. Closes: LP#74847, LP#61163
   * Dropped almost all patches from the package diff.gz since they have been
     adopted or obsoleted upstream. Only remaining change:
     - libgphoto2/gphoto2-filesys.c: Do not cache all downloaded files to plug
       a giant memory hole (see Debian bug #372166).
   * packaging/generic/{print-camera-list.c,check_ptp_camera}: Applied upstream
     SVN change 9562 to add and use an udev helper script to detect whether a
     USB device has a PtP compatible interface. This cannot be matched with a
     simple udev rule. Closes: LP#67532
   * debian/rules: Install check_ptp_camera to libgphoto2-2's lib/udev/.
   * debian/rules: Remove the 'make all-local' call, it does not work any more
     and is not necessary any more either.
   * debian/*.files{,.in}: Turn versions in paths into globs to match newer
     versions.
   * debian/libgphoto2-2.postinst: Call print-camera-list with mode and group
     arguments (this replaces the former source code patch.)

Changed in libgphoto2:
status: In Progress → Fix Released
Revision history for this message
towsonu2003 (towsonu2003) wrote :

requested fix in Edgy as per https://launchpad.net/ubuntu/+bug/77176/comments/3 and its responses.

Revision history for this message
Brian Ealdwine (eode) wrote :

Thank you!

> requested fix in Edgy as per
> https://launchpad.net/ubuntu/+bug/77176/comments/3 and its responses.
>

Revision history for this message
Martin Pitt (pitti) wrote :

I agree that this really sucks in Edgy. However, I have to cook up a new patch for Edgy.

Changed in libgphoto2:
assignee: nobody → pitti
status: Unconfirmed → In Progress
importance: Undecided → High
Revision history for this message
Brian Ealdwine (eode) wrote :

Thank you so very much for your attention to this issue in Edgy,
Martin. :-) It's greatly appreciated. I really hope to see Linux take
significant share in the desktop market, and I think Ubuntu is the
candidate for this; both for ease of use and for ideological standing.
Good luck!

~b

On Wed, 2007-01-10 at 08:22 +0000, Martin Pitt wrote:
> I agree that this really sucks in Edgy. However, I have to cook up a new
> patch for Edgy.
>
> ** Changed in: libgphoto2 (Ubuntu Edgy)
> Assignee: (unassigned) => Martin Pitt
> Status: Unconfirmed => In Progress
>
> ** Changed in: libgphoto2 (Ubuntu Edgy)
> Importance: Undecided => High
>

Revision history for this message
baaz (baaz) wrote :

Is this really a bug or i it just that the list of known devices in /etc/udev/rules.d/45-libgphoto2.rules is incomplete. I have a Canon Powershot A640 and got the same error. What I did was this:

$ lsusb
Bus 004 Device 031: ID 04a9:3139 Canon, Inc.

Then added the following line to /etc/udev/rules.d/45-libgphoto2.rules

SYSFS{idVendor}=="04a9", SYSFS{idProduct}=="3139", MODE="0660", GROUP="plugdev"

And everything works as a charm.

Cheers

/Baaz

Revision history for this message
Achim Bohnet (allee) wrote :

For the Kodak Easy Share V610 it's only outdated
45-libgphoto2.rules too.

--- 45-libgphoto2.rules.save 2007-01-21 10:54:09.000000000 +0100
+++ /etc/udev/rules.d/45-libgphoto2.rules 2007-01-21 10:55:20.000000000 +0100
@@ -351,6 +351,7 @@
 SYSFS{idVendor}=="040a", SYSFS{idProduct}=="0587", MODE="0660", GROUP="plugdev"
 SYSFS{idVendor}=="040a", SYSFS{idProduct}=="0580", MODE="0660", GROUP="plugdev"
 SYSFS{idVendor}=="040a", SYSFS{idProduct}=="0403", MODE="0660", GROUP="plugdev"
+SYSFS{idVendor}=="040a", SYSFS{idProduct}=="05ac", MODE="0660", GROUP="plugdev"
 SYSFS{idVendor}=="04c8", SYSFS{idProduct}=="0722", MODE="0660", GROUP="plugdev"
 SYSFS{idVendor}=="132b", SYSFS{idProduct}=="0001", MODE="0660", GROUP="plugdev"
 SYSFS{idVendor}=="132b", SYSFS{idProduct}=="0007", MODE="0660", GROUP="plugdev"

No problem in edgy then anymore with the camera.

Achim

Revision history for this message
baaz (baaz) wrote :

So all this just because libgphoto2 in the latest release of Ubuntu is outdated? ;)

ii libgphoto2-2 2.2.1-2ubuntu4 gphoto2 digital camera library

According to this page http://dehs.alioth.debian.org/wwiz_detail.php?id=8454283&type=up_changes some new releases of libgphoto2 has been released since 2.2.1 =)

My camera was added in 2.3.0 (2006-12-03)

Cheers

/Baaz

Revision history for this message
Brian Ealdwine (eode) wrote :

I think there's actually some other issue with it - it's supposed to
recognize them more generally, or some such. There's something on that
somewhere in this humongous bugreport, or in a bugreport linked to from
this one.

On Tue, 2007-01-30 at 23:31 +0000, baaz wrote:
> So all this just because libgphoto2 in the latest release of Ubuntu is
> outdated? ;)

Revision history for this message
Martin Pitt (pitti) wrote :

This recently got broken *again* in Feisty due to some reorganizations of /sys. Reopening for Feisty as well.

Changed in libgphoto2:
status: Fix Released → In Progress
Revision history for this message
Martin Pitt (pitti) wrote :

Got it.

Changed in libgphoto2:
status: In Progress → Fix Committed
Revision history for this message
Martin Pitt (pitti) wrote :

 libgphoto2 (2.3.0-0ubuntu2) feisty; urgency=low
 .
   * packaging/generic/print-camera-list.c: Ignore zero vendor IDs, since they
     will match on parent devices without a vendor/product ID (since we have to
     use ATTRS, not just ATTR). This avoids messing up other device's
     permissions. (LP: #76077)
   * packaging/generic/check_ptp_camera: Run with bash, since the script has
     some bashisms that avoid calling cat several times. This makes the script
     work again. (LP: #67532)
   * debian/control: Adapt maintainers for Ubuntu.

Changed in libgphoto2:
status: Fix Committed → Fix Released
Revision history for this message
Brian Ealdwine (eode) wrote :

Thanks, Martin. :-)

On Tue, 2007-02-13 at 16:54 +0000, Martin Pitt wrote:
> libgphoto2 (2.3.0-0ubuntu2) feisty; urgency=low
> .
> * packaging/generic/print-camera-list.c: Ignore zero vendor IDs, since they
> will match on parent devices without a vendor/product ID (since we have to
> use ATTRS, not just ATTR). This avoids messing up other device's
> permissions. (LP: #76077)
> * packaging/generic/check_ptp_camera: Run with bash, since the script has
> some bashisms that avoid calling cat several times. This makes the script
> work again. (LP: #67532)
> * debian/control: Adapt maintainers for Ubuntu.
>
>
> ** Changed in: libgphoto2 (Ubuntu)
> Status: Fix Committed => Fix Released
>

Revision history for this message
Alfredo Deza (arufuredosan) wrote :

Actually I had the same problem with a Canon PowerShot A60 and although I had this line: SYSFS{idVendor}=="04a9", SYSFS{idProduct}=="3074", MODE="0660", GROUP="plugdev"

It only worked when changing the permission to: MODE="0666"

I hope this works for someone else that came here looking for a solution and encountered the same problem as me.

Revision history for this message
Evgeny Kuznetsov (nekr0z) wrote :

aldegaz, you have to be sure you are in the "plugdev" group, otherwise your problem is understandable.

Revision history for this message
Alfredo Deza (arufuredosan) wrote :

I actually made it work just once and then the bug came back.

I finally found this that made all the difference in 2 computers with a clean Edgy Eft 6.10 install:

replace the third line in /etc/udev/rules.d/45-libgphoto2.rules:

BUS!="usb*", GOTO="libgphoto2_rules_end"

with
SUBSYSTEM!="usb_device", GOTO="libgphoto2_rules_end"

Revision history for this message
yct (juraj-vitko) wrote :

Exactly the same thing (as in the description of this bug) happened to me yesterday with my Kodak EasyShare DX4530, and I had to do the following downgrade to make it work again:

libgphoto2-2: 2.3.0-0ubuntu3~edgy2 --> 2.2.1-2ubuntu4
libgphoto2-port0: 2.3.0-0ubuntu3~edgy2 --> 2.2.1-2ubuntu4

To sum it up - it was working all the time, then after recent update it stopped to work, and after downgrading the packages, it worked again (immediatellly / no restart).

I'm not sure whether I should fill a new bug report for this.

Revision history for this message
W.P. van Paassen (wpvanpaassen) wrote :

Thanks aldegaz,

Your suggestion finally fixed the problem for my Kodak easyshare DX6490

Revision history for this message
Stefano Pedretti (stefano-pedretti) wrote :

Camera Canon powershot a530
(Device 031: ID 04a9:3126 Canon, Inc. )

Simply adding the line:
SYSFS{idVendor}=="04a9", SYSFS{idProduct}=="3126", MODE="0660", GROUP="plugdev"
does not solve the problem.

I've added a new file (/etc/udev/rules.d/45-canonpsa530.rules) with the same line and it solve the problem.

Revision history for this message
Evgeny Kuznetsov (nekr0z) wrote :

Stefano, in your situation I would check if your system is subject to bug #91250.

Revision history for this message
Byron Poland (wpoland) wrote :

Following aldegaz's instructions above, and changing the 3rd line in /etc/udev/rules.d/45-libgphoto2.rules to:

SUBSYSTEM!="usb_device", GOTO="libgphoto2_rules_end"

Fixed the problem with my Digital Rebel and PowerShot S500. I didn't really mess with my Rebel when working on this problem, but for the PowerShot, I noticed about 5 repeats of the device ID in the rules file for:

04a9:30b4 Canon, Inc. PowerShot S500

So it was always there in multiple!

Revision history for this message
DaveMcCollum (dave-mccollum) wrote :

Thanks to aldegaz and Byron. Fixed problem w/ Canon S400 as far as I can tell. Nice work gentlemen!

Yes, there seem to be many repeats in the .rules file for gphoto2....oh well!!

Revision history for this message
Josh Bowman (bowmanjj) wrote :

I am running Ubuntu Edgy, and encountered this bug while trying to import photos from a Kodak DC4800 camera. Following aldegaz's comment at:

https://bugs.launchpad.net/ubuntu/+source/libgphoto2/+bug/67532/comments/26

fixed the problem.

Revision history for this message
Niklas Edmundsson (niklas-edmundsson) wrote :

Indeed, editing /etc/udev/rules.d/45-libgphoto2.rules and replacing BUS with SUBSYSTEM makes it work.

Incidentally, this coincides with the output style from /usr/lib/libgphoto2/print-camera-list udev-rules-0.98 which is supposed to output a file usable by udev 0.98+...

Could it be so simple as libgphoto2-2.postinst being buggy? If I look at /etc/udev/rules.d/45-libgphoto2.rules it says it's for (udev < 0.98) but the installed udev is obviously newer than that... If that's the case, fix should be trivial. And developers should be embarassed ;)

This is on Ubuntu Feisty x86, libgphoto2-2 2.3.0-0ubuntu4, using a Panasonic DMC-FZ5 camera (recognized as FZ20 I think).

Revision history for this message
Tormod Volden (tormodvolden) wrote :

On a clean Feisty install (from Desktop CD) the /etc/udev/rules.d/45-libgphoto2.rules file uses SUBSYSTEM. After running sudo dpkg-reconfigure libgphoto2-2, it's still SUBSYSTEM. I don't understand why it doesn't work for you, Niklas.

Revision history for this message
Niklas Edmundsson (niklas-edmundsson) wrote :

This is a machine upgraded from edgy, and doing dpkg-reconfigure libgphoto2-2 indeed gives me a correct 45-libgphoto2.rules that has the comment about being for a new udev version.

I suspect that when doing an upgrade it's still running the old udev-version, and thus generates the file for the old version. When the machine finally gets around to running the new udev version (it might even take a reboot, I don't really know) it obviously will not work.

The kludge for the moment is of course doing dpkg-reconfigure on libgphoto2-2, I was too tired and frustrated to even think of that.

In the long run this should really be fixed in some sane way, you really shouldn't be expected to do dpkg-reconfigure on various packages in order for stuff to work after an upgrade.

Revision history for this message
Tormod Volden (tormodvolden) wrote :

Upgrading from Dapper to Edgy to Feisty worked fine here, I got SUBSYSTEM without any intervention.

Revision history for this message
Niklas Edmundsson (niklas-edmundsson) wrote :

The issue might be that the machine in question had edgy-backports (to get working gphoto2 stuff), and edgy-backports and feisty has the same libgphoto2-2 version.

Revision history for this message
Tormod Volden (tormodvolden) wrote :

The "Edgy" task has been marked "In Progress" for quite a while. Is there really any progress, or plans to fix this in Edgy? Martin?

Revision history for this message
Peter Whittaker (pwwnow) wrote :

Brand new Feisty install (fresh this morning, with all updates applied).

Two users: Me, my daughter. I create my account during the install process, add hers afterwards; she does not have admin privileges, has all other privileges (including plugdev membership).

Login to GDM as me, plug in Kodak C533: Import dialog appears.

Login to GDM as her, plug in Kodak C533: Nothing. Nada.

Logged in as her, run gnome-volume-manager-gthumb from command line without arguments. Receive following messages, but am able to import photos

    process 8234: arguments to dbus_message_new_method_call() were
    incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file
    dbus-message.c line 1074.
    This is normally a bug in some application using the D-Bus library.
    libhal.c 939 : Couldn't allocate D-BUS message
    error: libhal_device_get_property_type: (null): (null)
    hal_get_property.c 178 : INFO: called LIBHAL_FREE_DBUS_ERROR but
    dbusError was not set.

I've tried adding the ENV{} line to udev rules added immediately before device specific rules, after gotos); tried setting the device specific permission to 0666, tried giving her admin privileges, nothing works. By "nothing works" I mean that the import dialog only appears for me and not for her.

I've also verified /etc/passwd* and /etc/group* and everything looks good (plugdev membership, etc.). But only my account, the first user account (uid 1000) has success, her account (uid 1001) gets no dialogs and the command line error above).

If this is another bug, let me know, I'll add this report to that bug.

Revision history for this message
Brian Ealdwine (eode) wrote :

> process 8234: arguments to dbus_message_new_method_call() were
> incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file
> dbus-message.c line 1074.
> This is normally a bug in some application using the D-Bus library.
> libhal.c 939 : Couldn't allocate D-BUS message
> error: libhal_device_get_property_type: (null): (null)
> hal_get_property.c 178 : INFO: called LIBHAL_FREE_DBUS_ERROR but
> dbusError was not set.
>

This is different bug, I'm pretty sure. I'll correspond with you and
try to work out a couple things, but it might be a decent thing to file
a bug report about anyway.

Revision history for this message
Peter Whittaker (pwwnow) wrote :

Brian, thanks for your assistance, you were right, this is indeed a different bug.

Folks, the camera works fine for all users of this machine except one, whose ${HOME} and all .g* settings were created under Edgy. I've created new users on this machine and they see the camera just fine.

I suspect the problems I reported above may have something to do with the path this machine took: Dapper install from CD, Edgy Beta upgrade on-line, Edgy final upgrade on-line, Feisty beta upgrade on-line, and, finally, fresh install from Feisty CD, overwriting /, leaving /home in place. Somewhere in there, ~/.* settings got mangled and broke the camera import detection for this one user. Definitely a different bug, please disregard comments above (comment#40).

Revision history for this message
nobtiba (nghevd) wrote :

Dear all,

I am working with Aiptek mini Pencam 1.3, Vendor ID 04fc; Product ID: 504a. Then i did the fix for both bug 64146, bug 67532 and bug 91250
add a line: SYSFS{idVendor}=="04fc", SYSFS{idProduct}=="504a", MODE="0660", GROUP="plugdev"
and
changing the BUS!="usb*"... line to SUBSYSTEM!="usb_device"...
or add a line :
ENV{INTERFACE}=="6/1/1", MODE="0660", GROUP="plugdev"

But nothing can help! I still got the following error when trying to
access the camera to get info or download picture (by gphoto 2):

 gphoto2 --camera "Aiptek Pencam" --port "usb:001,016" --list-files

*** Error ***
An error occurred in the io-library ('Could not claim the USB device'): Could not claim interface 0 (Device or resource busy). Make sure no other program or kernel module (such as sdc2xx, stv680, spca50x) is using the device and you have read/write access to the device.
*** Error (-53: 'Could not claim the USB device') ***

For debugging messages, please use the --debug option.
Debugging messages may help finding a solution to your problem.
If you intend to send any error or debug messages to the gphoto
developer mailing list <email address hidden>, please run
gphoto2 as follows:

    env LANG=C gphoto2 --debug --debug-logfile=my-logfile.txt --camera
"Aiptek Pencam" --port "usb:001,016" --list-files

Please make sure there is sufficient quoting around the arguments.

Revision history for this message
Marcus Meissner (meissner) wrote :

On Fri, Dec 07, 2007 at 06:07:51AM -0000, nobtiba wrote:
> Dear all,
>
> I am working with Aiptek mini Pencam 1.3, Vendor ID 04fc; Product ID: 504a. Then i did the fix for both bug 64146, bug 67532 and bug 91250
> add a line: SYSFS{idVendor}=="04fc", SYSFS{idProduct}=="504a", MODE="0660", GROUP="plugdev"
> and
> changing the BUS!="usb*"... line to SUBSYSTEM!="usb_device"...
> or add a line :
> ENV{INTERFACE}=="6/1/1", MODE="0660", GROUP="plugdev"
>
> But nothing can help! I still got the following error when trying to
> access the camera to get info or download picture (by gphoto 2):
>
> gphoto2 --camera "Aiptek Pencam" --port "usb:001,016" --list-files
>
> *** Error ***
> An error occurred in the io-library ('Could not claim the USB device'): Could not claim interface 0 (Device or resource busy). Make sure no other program or kernel module (such as sdc2xx, stv680, spca50x) is using the device and you have read/write access to the device.
> *** Error (-53: 'Could not claim the USB device') ***

This is not about permissions.

This means another process or kernel module is accessing this device.

Ciao, Marcus

Revision history for this message
nobtiba (nghevd) wrote :

So how could I suppose to do to get the camera free for downloading and other accessing ?

Regards,

Nghe

-----Original Message-----
From: <email address hidden> on behalf of Marcus Meissner
Sent: Fri 12/7/2007 4:20 PM
To: Vuong Dao Nghe
Subject: Re: [Bug 67532] Re: udev-rule for PTP class detection broken

On Fri, Dec 07, 2007 at 06:07:51AM -0000, nobtiba wrote:
> Dear all,
>
> I am working with Aiptek mini Pencam 1.3, Vendor ID 04fc; Product ID: 504a. Then i did the fix for both bug 64146, bug 67532 and bug 91250
> add a line: SYSFS{idVendor}=="04fc", SYSFS{idProduct}=="504a", MODE="0660", GROUP="plugdev"
> and
> changing the BUS!="usb*"... line to SUBSYSTEM!="usb_device"...
> or add a line :
> ENV{INTERFACE}=="6/1/1", MODE="0660", GROUP="plugdev"
>
> But nothing can help! I still got the following error when trying to
> access the camera to get info or download picture (by gphoto 2):
>
> gphoto2 --camera "Aiptek Pencam" --port "usb:001,016" --list-files
>
> *** Error ***
> An error occurred in the io-library ('Could not claim the USB device'): Could not claim interface 0 (Device or resource busy). Make sure no other program or kernel module (such as sdc2xx, stv680, spca50x) is using the device and you have read/write access to the device.
> *** Error (-53: 'Could not claim the USB device') ***

This is not about permissions.

This means another process or kernel module is accessing this device.

Ciao, Marcus

--
udev-rule for PTP class detection broken
https://bugs.launchpad.net/bugs/67532
You received this bug notification because you are a direct subscriber
of a duplicate bug.

Revision history for this message
Brian Ealdwine (eode) wrote :

fuser -uv /dev/usbx

where /dev/usbx is the device for your camera.

That will give you the process ID, account username, and command of any
process using that device.

..This should be started as a separate bug, since the two problems
(permissions, and blocking as already used) aren't the same. Feel free
to email me with questions, I'll help out where I can -- however, I'm
very busy, and it may take a while to respond.

-brian

Revision history for this message
nobtiba (nghevd) wrote :

Hi,

Thank you for suggestion. In fact, i tried to work with fuser but not sure what to replace /dev/usbx
From: gphoto2 --auto-detect i get:
Model Port
----------------------------------------------------------
Aiptek Pencam usb:
Aiptek Pencam usb:001,020
Aiptek Pencam usb:001,019
I tried

fuser -uv /dev/usb:001,020 but it said
Cannot stat /dev/usb:001,020: No such file or directory

Then I tried:

fuser -uv /Aiptek Pencam
fuser -uv /dev/usb/Aiptek Pencam
fuser -uv /AiptekPencam

but no one seems to be the right command.

So could you tell me a bit more detail how should i do to debug the error since i was only a beginner

Thank you !
-----Original Message-----
From: <email address hidden> on behalf of Brian Visel
Sent: Sat 12/8/2007 12:22 AM
To: Vuong Dao Nghe
Subject: RE: [Bug 67532] Re: udev-rule for PTP class detection broken

fuser -uv /dev/usbx

where /dev/usbx is the device for your camera.

That will give you the process ID, account username, and command of any
process using that device.

..This should be started as a separate bug, since the two problems
(permissions, and blocking as already used) aren't the same. Feel free
to email me with questions, I'll help out where I can -- however, I'm
very busy, and it may take a while to respond.

-brian

--
udev-rule for PTP class detection broken
https://bugs.launchpad.net/bugs/67532
You received this bug notification because you are a direct subscriber
of a duplicate bug.

Revision history for this message
Brian Ealdwine (eode) wrote :

nobtiba:

Seriously, this is the wrong bug to be discussing this on. You need to
create a new bug. You can email me directly once you've done so, and
I'll be happy to help out there. Mixing bugs confuses everyone and
creates all kinds of problems.

-Brian

Revision history for this message
Martin Pitt (pitti) wrote :

Edgy goes out of support in about a month, so it's not worth doing such a fix now (especially since it has never been pinned down properly and attempted to get fixed several times). It has been fixed properly in Feisty (7.04) and beyond.

Changed in libgphoto2:
assignee: pitti → nobody
status: In Progress → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.