Hi,
On Fri, Jun 10, 2011 at 05:43:06PM -0500, Theodore Kilgore wrote:
there's nothing in the USB spec that says you need different product IDs
for different modes of operation. No matter if it's still or webcam
configuration, the underlying function is the same: capture images using
a set
Em 13-06-2011 06:05, Felipe Balbi escreveu:
Hi,
On Fri, Jun 10, 2011 at 05:43:06PM -0500, Theodore Kilgore wrote:
there's nothing in the USB spec that says you need different product IDs
for different modes of operation. No matter if it's still or webcam
configuration, the underlying
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
On Sun, 12 Jun 2011, Hans de Goede wrote:
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
On Mon, Jun 13, 2011 at 5:20 AM, Theodore Kilgore
kilg...@banach.math.auburn.edu wrote:
On Sun, 12 Jun 2011, Hans de Goede wrote:
Actually libusb and libgphoto have been using the rebind orginal driver
functionality of the code for quite a while now,
Oh? I can see that libusb is doing that,
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
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 +
On Sat, 11 Jun 2011, Hans de Goede wrote:
So what do we need to make this situation better:
1) A usb_driver callback alternative to the disconnect callback,
I propose to call this soft_disconnect. This serves 2 purposes
a) It will allow the driver to tell the caller that that is
Hi,
On Fri, Jun 10, 2011 at 09:55:13AM +0200, Hans de Goede wrote:
Currently this will cause the usb mass storage driver to see a
disconnect, and any possible still pending writes are lost ...
This is IMHO unacceptable, but currently there is nothing we can
do to avoid this.
2) So called
Hi,
On 06/10/2011 10:22 AM, Felipe Balbi wrote:
Hi,
On Fri, Jun 10, 2011 at 09:55:13AM +0200, Hans de Goede wrote:
Currently this will cause the usb mass storage driver to see a
disconnect, and any possible still pending writes are lost ...
This is IMHO unacceptable, but currently there is
Hi,
On Fri, Jun 10, 2011 at 10:36:47AM +0200, Hans de Goede wrote:
On Fri, Jun 10, 2011 at 09:55:13AM +0200, Hans de Goede wrote:
Currently this will cause the usb mass storage driver to see a
disconnect, and any possible still pending writes are lost ...
This is IMHO unacceptable, but
Hi,
On 06/10/2011 10:42 AM, Felipe Balbi wrote:
Hi,
On Fri, Jun 10, 2011 at 10:36:47AM +0200, Hans de Goede wrote:
On Fri, Jun 10, 2011 at 09:55:13AM +0200, Hans de Goede wrote:
snip
So what do we need to make this situation better:
1) A usb_driver callback alternative to the disconnect
Hi,
On Fri, Jun 10, 2011 at 02:19:20PM +0200, Hans de Goede wrote:
So what do we need to make this situation better:
1) A usb_driver callback alternative to the disconnect callback,
I propose to call this soft_disconnect. This serves 2 purposes
a) It will allow the driver to tell the
On Fri, 10 Jun 2011, Hans de Goede wrote:
Hi all,
The current API for managing kernel - userspace is a bit
rough around the edges, so I would like to discuss extending
the API.
First of all an example use case scenarios where the current API
falls short.
1) Redirection of USB devices
Em 10-06-2011 11:48, Alan Stern escreveu:
On Fri, 10 Jun 2011, Hans de Goede wrote:
As Felipe has mentioned, this sounds like the sort of problem that
can better be solved in userspace. A dual-mode device like the one
you describe really is either a still-cam or a webcam, never both at
On Fri, 10 Jun 2011, Mauro Carvalho Chehab wrote:
Em 10-06-2011 11:48, Alan Stern escreveu:
On Fri, 10 Jun 2011, Hans de Goede wrote:
As Felipe has mentioned, this sounds like the sort of problem that
can better be solved in userspace. A dual-mode device like the one
you
Hi,
On Fri, Jun 10, 2011 at 01:16:47PM -0500, Theodore Kilgore wrote:
As I have been involved in writing the drivers (both the kernel and the
libgphoto2 drivers) for many of the affected cameras, perhaps I should
expand on this problem. There are lots of responses to this original
message
On Fri, 10 Jun 2011, Hans de Goede wrote:
Hi all,
The current API for managing kernel - userspace is a bit
rough around the edges, so I would like to discuss extending
the API.
[...]
2) So called dual mode cameras are (cheap) stillcams often even
without an lcdscreen viewfinder, and
On Fri, 10 Jun 2011, Felipe Balbi wrote:
I don't see any problems in this situation. If, for that particular
product, webcam and still image functionality are mutually exclusive,
then that's how the product (and their drivers) have to work.
If the linux community decided to put webcam
Hi,
On Fri, Jun 10, 2011 at 05:18:39PM -0400, Alan Stern wrote:
2. Until recently in the history of Linux, there was an irreconcilable
conflict. If a kernel driver for the video streaming mode was present and
installed, it was not possible to use the camera in stillcam mode at all.
On Fri, 10 Jun 2011, Felipe Balbi wrote:
Hi,
On Fri, Jun 10, 2011 at 01:16:47PM -0500, Theodore Kilgore wrote:
As I have been involved in writing the drivers (both the kernel and the
libgphoto2 drivers) for many of the affected cameras, perhaps I should
expand on this problem. There
On Fri, 10 Jun 2011, Alan Stern wrote:
On Fri, 10 Jun 2011, Felipe Balbi wrote:
I don't see any problems in this situation. If, for that particular
product, webcam and still image functionality are mutually exclusive,
then that's how the product (and their drivers) have to work.
On Sat, Jun 11, 2011 at 6:43 AM, Theodore Kilgore
kilg...@banach.math.auburn.edu wrote:
I do not believe that we have found the optimal solution, yet. The ideal
thing would be some kind of hack which allows the kernel to be used when
it is needed, and when it is not needed it does not
23 matches
Mail list logo
