Hi,
On 06/11/2011 06:19 PM, Theodore Kilgore wrote:
On Sat, 11 Jun 2011, Hans de Goede wrote:
Hi,
Given the many comments in this thread, I'm just
going reply to this one, and try to also answer any
other ones in this mail.
As far as the dual mode camera is involved, I agree
that that should be fixed in the existing v4l2
drivers + libgphoto. I think that Felipe's solution
to also handle the stillcam part in kernel space for
dual mode cameras (and add a libgphoto cam driver which
knows how to talk the new kernel API for this), is
the best solution. Unfortunately this will involve
quite a bit of work, but so be it.
Hans,
It appears to me that the solution ought to be at hand, actually.
I was not aware of the recent changes in libusb, which I understand are
supposed to allow a kernel driver to be hooked up again.
To review the situation:
1. As of approximately 2 years ago, libusb already was so configured as to
suspend the kernel module for a dual-mode device if a userspace-based
program tried to claim the device.
2. At this point with the more recent versions of libusb (see the last
message from yesterday, from Xiaofan Chen), we are supposed to be able to
re-activate the kernel module for the device when it is relinquished by
userspace.
This ought to take care of the problems completely, provided that the new
capabilities of libusb are actually used and called upon in libgphoto2.
I have checked on what is happening, just now, on my own machine. I have
libusb version 1.08 which ought to be recent enough. The advertised
abilities did not work, however. Presumably, what is missing is on the
other end of the problem, most likely in the functions in libgphoto2 which
hook up a camera. That code would presumably need to call upon the new
functionality of libusb. My currently installed version of libgphoto2
(from svn, but several months old) clearly does not contain the needed
functionality. But it might have been put in recently and I did not
notice. I guess that the first thing to do is to update my gphoto tree and
then to see what happens. If things still don't work, then something needs
to be updated and then things ought to work.
I will try to see that something gets done about this. Thank you for
raising the old issue of dual-mode devices yet again, and thanks to
Xiaofan Chen for pointing out that the needed missing half of the
functionality is supposed to exist now in libusb. That had escaped my
attention.
Actually libusb and libgphoto have been using the rebind orginal driver
functionality of the code for quite a while now, unfortunately this
does not solve the problem, unless we somehow move to 1 central
coordinator for the device the user experience will stay subpar.
Example, user downloads pictures from the camera using shotwell,
gthumb, fspot or whatever, keeps the app in question open and the app
in question keeps the gphoto2 device handle open.
User wants to do some skyping with video chat, skype complains it
cannot find the device, since the kernel driver currently is unbound.
-> Poor user experience.
With having both functions in the kernel, the kernel could actually
allow skype to use the dual mode cameras as video source, and if
the user then were to switch to f-spot and try to import more photo's
then he will get an -ebusy in f-spot. If he finishes skyping and
then returns to f-spot everything will just continue working.
This is the kind of "seamless" user experience I'm aiming for here.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
