Hi, I'm working on improving Fedora support of so called dual mode camera's. Dual mode camera's are cheap still camera's usually with low res sensors and battery backed sram as storage, which can also function as webcams. As part of the better webcam support push I've been doing for a while now: http://fedoraproject.org/wiki/Features/BetterWebcamSupportF13 I'm focussing for F-13 on getting these cameras to work out of the box as webcams. The driver side is coming together nicely, but with some cameras gvfs / gio decides to automount them. What happens is a "foo camera" drive show up in places->computer and it is mounted by default. This causes 2 issues: 1) The gthumb-importer which also pops up complains that it cannot talk to the device 2) The webcam driver fails to initialize the device properly, as it gets a disconnect half way through initializing Note I'm not saying this is nautilus' fault, but I'm not familiar enough with how the gnome desktop decides to take certain actions (yet), to find a better component to file a bug against. The camera(s) where I'm seeing this with all are based on the stv0680 chipset, usb id: 0553:0202 (seen with 2 different model cams with the same id). The funny thing is that looking at the udev rules / hal fdi info, there is no difference between these cams and another dual mode camera I have based on the mr97310a chipset with usb id 093a:010e, which when plugged in after logging in to the desktop causes neither gvfs/gio (good) nor gthumb-importer (bad) too touch it.
David, Adding you to the CC, because I think / hope you have some insight on this, can you please give some input on this (see original description) issue, Thanks, Hans
(In reply to comment #0) > Hi, > > I'm working on improving Fedora support of so called dual mode > camera's. Dual mode camera's are cheap still camera's usually with low res > sensors and battery backed sram as storage, which can also function as webcams. Please attach lsusb output. Also, please attach the output of udevadm info -q all -n /dev/bus/usb/X/Y where X and Y are numbers for the bus and device. > The driver side is coming together nicely, but with some cameras gvfs / gio > decides to automount them. What happens is a "foo camera" drive show up in > places->computer and it is mounted by default. Need some more info here: Is the webcam driver user- or kernel-mode? Is the webcam and PTP device on separate interfaces? FWIW, there's a problem with the way the USB stack in Linux currently works - we only get a device node per device, not per interface. So if the USB device has both a PTP and webcam USB interface I'm not sure how things are going to work. > This causes 2 issues: > 1) The gthumb-importer which also pops up complains that it cannot talk to > the device This is probably just a gthumb problem - e.g. gthumb has not been ported to use GIO/GVfs - e.g. gthumb tries to talk to the USB device directly (via gphoto2) but that fails because the gvfsd-gphoto2 process is already using the device and USB is single-opener). Can you browse the contents of the device via Nautilus though? Does gvfs-ls gphoto2://[usb:X,Y]/ work? (use 'gvfs-mount -l' to find the values for X and Y - it's the bus and device number) (Remember you need to use the gvfs-* commands from a shell inside the desktop session - it won't work if you try it from a root- or ssh-shell.) > 2) The webcam driver fails to initialize the device properly, as it gets a > disconnect half way through initializing Does this work if you kill the gvfsd-gphoto2 process that claims the device? (One way to kill the process is to unmount the camera in Nautilus... killall or pkill works too.)
Created attachment 381655 [details] lsusb -vvv output
Created attachment 381656 [details] udevadm info -q all -n /dev/bus/usb/002/004 output
(In reply to comment #2) > (In reply to comment #0) > > Hi, > > > > I'm working on improving Fedora support of so called dual mode > > camera's. Dual mode camera's are cheap still camera's usually with low res > > sensors and battery backed sram as storage, which can also function as webcams. > > Please attach lsusb output. Also, please attach the output of > > udevadm info -q all -n /dev/bus/usb/X/Y > > where X and Y are numbers for the bus and device. > > > The driver side is coming together nicely, but with some cameras gvfs / gio > > decides to automount them. What happens is a "foo camera" drive show up in > > places->computer and it is mounted by default. > > Need some more info here: > > Is the webcam driver user- or kernel-mode? > kernel mode. > Is the webcam and PTP device on separate interfaces? > One interface with a proprietary protocol which can be used both to download still images, or to put the camera in webcam mode and stream. > FWIW, there's a problem with the way the USB stack in Linux currently works - > we only get a device node per device, not per interface. So if the USB device > has both a PTP and webcam USB interface I'm not sure how things are going to > work. > > > This causes 2 issues: > > 1) The gthumb-importer which also pops up complains that it cannot talk to > > the device > > This is probably just a gthumb problem - e.g. gthumb has not been ported to use > GIO/GVfs - e.g. gthumb tries to talk to the USB device directly (via gphoto2) > but that fails because the gvfsd-gphoto2 process is already using the device > and USB is single-opener). > > Can you browse the contents of the device via Nautilus though? Does gvfs-ls > gphoto2://[usb:X,Y]/ work? (use 'gvfs-mount -l' to find the values for X and Y > - it's the bus and device number) > I haven't tried this (there are no batteries in the camera atm). > (Remember you need to use the gvfs-* commands from a shell inside the desktop > session - it won't work if you try it from a root- or ssh-shell.) > > > 2) The webcam driver fails to initialize the device properly, as it gets a > > disconnect half way through initializing > > Does this work if you kill the gvfsd-gphoto2 process that claims the device? > > (One way to kill the process is to unmount the camera in Nautilus... killall or > pkill works too.) Using umount frees up the device for use by the kernel driver, but I need to rmmod and re insmod it, for some reason no signal is send to the kernel to re-attach the driver. Note that gphoto2 itself does to this properly (re-attach the kernel driver after use).
After discussing this on IRC it turns out this is a combination of 1. the good old "gvfsd-gphoto2 keeps the device open" problem 2. (cheap?) hardware where multiple functions are combined into USB interface The most viable approach might be to change gvfsd-gphoto2 so it only keeps the device open when actually using it. Thus, reassigning to GVfs for now.
Filed upstream here: https://bugzilla.gnome.org/show_bug.cgi?id=606058
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Dual mode cameras still don't provide a nice user experience in F-15...
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.