Hi,
On Mon, Jun 13, 2011 at 10:06:58AM -0300, Mauro Carvalho Chehab wrote:
> 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 diffe
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 underl
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
>
On Jun 12, 2011, at 7:03 PM, Xiaofan Chen wrote:
On Mon, Jun 13, 2011 at 5:20 AM, Theodore Kilgore
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
On Mon, Jun 13, 2011 at 5:20 AM, Theodore Kilgore
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, and I can also see that t
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
> >
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 shou
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 t
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
> drive
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, Xiaofan Chen wrote:
> On Sat, Jun 11, 2011 at 6:43 AM, Theodore Kilgore
> 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 ne
On Sat, Jun 11, 2011 at 6:43 AM, Theodore Kilgore
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 interfere.
Just wondering if you can
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 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 proble
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
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 f
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
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
> messa
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
> >
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 bot
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 U
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
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:
So what do we need to make this situation better:
1) A usb_driver callback alternative to the disconnect callba
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 unaccepta
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 no
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
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 to a virtual machine, qemu, vbox, etc.
all have the
27 matches
Mail list logo
