Hi Mauro,
On Wed, Aug 03, 2011 at 02:21:05PM -0300, Mauro Carvalho Chehab wrote:
As already announced, we're continuing the planning for this year's
media subsystem workshop.
To avoid overriding the main ML with workshop-specifics, a new ML
was created:
workshop-2...@linuxtv.org
Em 11-08-2011 07:16, Sakari Ailus escreveu:
Hi Mauro,
On Wed, Aug 03, 2011 at 02:21:05PM -0300, Mauro Carvalho Chehab wrote:
As already announced, we're continuing the planning for this year's
media subsystem workshop.
To avoid overriding the main ML with workshop-specifics, a new ML
Hi,
On 08/10/2011 02:34 AM, Theodore Kilgore wrote:
snip
but this is the way how
the current discussion feels to me. If we agree on aiming for
doing it right then with that comes to me doing a software
design from scratch, so without taking into account what is
already there.
Here, a
Hi,
On 08/08/2011 07:39 PM, Theodore Kilgore wrote:
On Mon, 8 Aug 2011, Mauro Carvalho Chehab wrote:
snip
Mauro,
In fact none of the currently known and supported cameras are using PTP.
All of them are proprietary. They have a rather intimidating set of
differences in functionality,
Hi,
snip
OK, another example. The cameras supported in camlibs/jl2005c do not have
webcam ability, but someone could at any time design and market a dualmode
which has in stillcam mode the same severe limitation. What limitation?
Well, the entire memory of the camera must be dumped, or else
On Tue, 9 Aug 2011, Hans de Goede wrote:
Hi,
On 08/08/2011 07:39 PM, Theodore Kilgore wrote:
On Mon, 8 Aug 2011, Mauro Carvalho Chehab wrote:
snip
Mauro,
In fact none of the currently known and supported cameras are using PTP.
All of them are proprietary. They have
On Tue, 9 Aug 2011, Hans de Goede wrote:
Hi,
snip
OK, another example. The cameras supported in camlibs/jl2005c do not have
webcam ability, but someone could at any time design and market a dualmode
which has in stillcam mode the same severe limitation. What limitation?
Well, the
Hi,
On 08/09/2011 07:10 PM, Theodore Kilgore wrote:
On Tue, 9 Aug 2011, Hans de Goede wrote:
snip
No, but both Adam and I realized, approximately at the same time
yesterday afternoon, something which is rather important here. Gphoto is
not developed exclusively for Linux. Furthermore, it
On Tue, 9 Aug 2011, Hans de Goede wrote:
Hi,
On 08/09/2011 07:10 PM, Theodore Kilgore wrote:
On Tue, 9 Aug 2011, Hans de Goede wrote:
snip
No, but both Adam and I realized, approximately at the same time
yesterday afternoon, something which is rather important here. Gphoto
Hi,
On 08/08/2011 12:53 AM, Adam Baker wrote:
On Friday 05 August 2011, Hans de Goede wrote:
This sounds to be a good theme for the Workshop, or even to KS/2011.
Agreed, although we don't need to talk about this for very long, the
solution is basically:
1) Define a still image retrieval API
Em 07-08-2011 23:26, Theodore Kilgore escreveu:
(first of two replies to Adam's message; second reply deals with other
topics)
On Sun, 7 Aug 2011, Adam Baker wrote:
On Friday 05 August 2011, Hans de Goede wrote:
This sounds to be a good theme for the Workshop, or even to KS/2011.
On Mon, 8 Aug 2011, Adam Baker wrote:
Further testing reveals the situation is more complex than I first thought -
the behaviour I get depends upon whether what gets plugged in is a full speed
or a high speed device. After I've run the test of running gphoto whilst
streaming from a
On Sun, 7 Aug 2011, Theodore Kilgore wrote:
This indirectly answers my question, above, about whatever device there
may or may not be. What I get from this, and also from a bit of snooping
around, is that there is not any dev that gets created in order to be
accessed by libusb. Just an
On Mon, 8 Aug 2011, Mauro Carvalho Chehab wrote:
Em 07-08-2011 23:26, Theodore Kilgore escreveu:
(first of two replies to Adam's message; second reply deals with other
topics)
On Sun, 7 Aug 2011, Adam Baker wrote:
On Friday 05 August 2011, Hans de Goede wrote:
This sounds
On Mon, 8 Aug 2011, Alan Stern wrote:
On Sun, 7 Aug 2011, Theodore Kilgore wrote:
This indirectly answers my question, above, about whatever device there
may or may not be. What I get from this, and also from a bit of snooping
around, is that there is not any dev that gets created in
Em 08-08-2011 14:39, Theodore Kilgore escreveu:
On Mon, 8 Aug 2011, Mauro Carvalho Chehab wrote:
Em 07-08-2011 23:26, Theodore Kilgore escreveu:
(first of two replies to Adam's message; second reply deals with other
topics)
On Sun, 7 Aug 2011, Adam Baker wrote:
On Friday 05 August
On Mon, 8 Aug 2011, Theodore Kilgore wrote:
On Mon, 8 Aug 2011, Alan Stern wrote:
On Sun, 7 Aug 2011, Theodore Kilgore wrote:
This indirectly answers my question, above, about whatever device there
may or may not be. What I get from this, and also from a bit of snooping
around,
On Mon, 8 Aug 2011, Mauro Carvalho Chehab wrote:
Em 08-08-2011 14:39, Theodore Kilgore escreveu:
On Mon, 8 Aug 2011, Mauro Carvalho Chehab wrote:
Em 07-08-2011 23:26, Theodore Kilgore escreveu:
(first of two replies to Adam's message; second reply deals with other
topics)
On Mon, 8 Aug 2011, Alan Stern wrote:
On Mon, 8 Aug 2011, Theodore Kilgore wrote:
On Mon, 8 Aug 2011, Alan Stern wrote:
On Sun, 7 Aug 2011, Theodore Kilgore wrote:
This indirectly answers my question, above, about whatever device there
may or may not be. What I get from
Em 08-08-2011 16:32, Theodore Kilgore escreveu:
Doing an specific libusb-like approach just for those cams seems to be the
wrong direction, as such driver would be just a fork of an already existing
code. I'm all against duplicating it.
Well, in practice the fork would presumably be carried
On Monday 08 August 2011, Mauro Carvalho Chehab wrote:
Well, in practice the fork would presumably be carried out by yours
truly. Presumably with the advice and help of concerned parties. too.
Since I am involved on both the kernel side and the libgphoto2 side of
the support for
On Monday 08 August 2011, Mauro Carvalho Chehab wrote:
I will send a second reply to this message, which deals in particular
with the list of abilities you outlined above. The point is, the
situation as to that list of abilities is more chaotic than is generally
realized. And when people
On Mon, 8 Aug 2011, Theodore Kilgore wrote:
Maybe a good compromise would be to create a kind of stub driver that
could negotiate the device access while still delegating most of the
real work to userspace.
Hooray. This appears to me to be a very good solution.
I'm not so
On Mon, 8 Aug 2011, Adam Baker wrote:
On Monday 08 August 2011, Mauro Carvalho Chehab wrote:
Well, in practice the fork would presumably be carried out by yours
truly. Presumably with the advice and help of concerned parties. too.
Since I am involved on both the kernel side
On Mon, 8 Aug 2011, Adam Baker wrote:
On Monday 08 August 2011, Mauro Carvalho Chehab wrote:
I will send a second reply to this message, which deals in particular
with the list of abilities you outlined above. The point is, the
situation as to that list of abilities is more chaotic
On Friday 05 August 2011, Hans de Goede wrote:
This sounds to be a good theme for the Workshop, or even to KS/2011.
Agreed, although we don't need to talk about this for very long, the
solution is basically:
1) Define a still image retrieval API for v4l2 devices (there is only 1
On Sun, 7 Aug 2011, Adam Baker wrote:
I've addec Hans de Geode and linux-usb to the CC as this response picks up on
a related discussion about the usb mini summit.
On Friday 05 August 2011, Theodore Kilgore wrote:
If you can solve the locking problem between devices in the kernel then
On Monday 08 August 2011, Alan Stern wrote:
On Sun, 7 Aug 2011, Adam Baker wrote:
I've addec Hans de Geode and linux-usb to the CC as this response picks
up on a related discussion about the usb mini summit.
On Friday 05 August 2011, Theodore Kilgore wrote:
If you can solve the
(first of two replies to Adam's message; second reply deals with other
topics)
On Sun, 7 Aug 2011, Adam Baker wrote:
On Friday 05 August 2011, Hans de Goede wrote:
This sounds to be a good theme for the Workshop, or even to KS/2011.
Agreed, although we don't need to talk about this
On Sun, 7 Aug 2011, Alan Stern wrote:
On Sun, 7 Aug 2011, Adam Baker wrote:
I've addec Hans de Geode and linux-usb to the CC as this response picks up
on
a related discussion about the usb mini summit.
On Friday 05 August 2011, Theodore Kilgore wrote:
If you can solve the
Hi all,
On 08/04/2011 02:34 PM, Mauro Carvalho Chehab wrote:
Em 03-08-2011 20:20, Theodore Kilgore escreveu:
snip snip
Yes, that kind of thing is an obvious problem. Actually, though, it may be
that this had just better not happen. For some of the hardware that I know
of, it could be a real
On Fri, 5 Aug 2011, Hans de Goede wrote:
Hi all,
On 08/04/2011 02:34 PM, Mauro Carvalho Chehab wrote:
Em 03-08-2011 20:20, Theodore Kilgore escreveu:
snip snip
Yes, that kind of thing is an obvious problem. Actually, though, it may be
that this had just better not happen. For
Hi,
On 08/03/2011 10:36 PM, Mauro Carvalho Chehab wrote:
Em 03-08-2011 16:53, Theodore Kilgore escreveu:
snip snip
Mauro,
Not saying that you need to change the program for this session to deal
with this topic, but an old and vexing problem is dual-mode devices. It is
an issue which needs
Em 04-08-2011 08:39, Hans de Goede escreveu:
Hi,
On 08/03/2011 10:36 PM, Mauro Carvalho Chehab wrote:
Em 03-08-2011 16:53, Theodore Kilgore escreveu:
snip snip
Mauro,
Not saying that you need to change the program for this session to deal
with this topic, but an old and vexing
On Thu, 04 Aug 2011 09:40:18 -0300
Mauro Carvalho Chehab mche...@redhat.com wrote:
What we need for this is a simple API (new v4l ioctl's I guess) for the
stillcam mode of these dual mode cameras (stillcam + webcam). So that the
webcam drivers can grow code to also allow access to the
(re-adding all from the original CC-list, please, don't drop anyone)
On Thu, 4 Aug 2011, Jean-Francois Moine wrote:
On Thu, 04 Aug 2011 09:40:18 -0300
Mauro Carvalho Chehab mche...@redhat.com wrote:
What we need for this is a simple API (new v4l ioctl's I guess) for the
stillcam mode
On Thursday 04 August 2011, Theodore Kilgore wrote:
As far as I know, /dev/sdx signifies a device which is accessible by
something like the USB mass storage protocols, at the very least. So, if
that fits the camera, fine. But most of the cameras in question are Class
Proprietary. Thus, not
On Thursday 04 August 2011, Mauro Carvalho Chehab wrote:
That'd also be my understanding. There are already several standard ways
to access data on still cameras: mass-storage, PTP, MTP, why invent Yet
Another One? Just learn to share a device between several existing
drivers.
For
Em 04-08-2011 18:38, Adam Baker escreveu:
On Thursday 04 August 2011, Mauro Carvalho Chehab wrote:
That'd also be my understanding. There are already several standard ways
to access data on still cameras: mass-storage, PTP, MTP, why invent Yet
Another One? Just learn to share a device
On Thu, 4 Aug 2011, Adam Baker wrote:
On Thursday 04 August 2011, Theodore Kilgore wrote:
As far as I know, /dev/sdx signifies a device which is accessible by
something like the USB mass storage protocols, at the very least. So, if
that fits the camera, fine. But most of the cameras in
On Thu, 4 Aug 2011, Adam Baker wrote:
On Thursday 04 August 2011, Mauro Carvalho Chehab wrote:
That'd also be my understanding. There are already several standard ways
to access data on still cameras: mass-storage, PTP, MTP, why invent Yet
Another One? Just learn to share a device
On Thursday 04 August 2011, Theodore Kilgore wrote:
On Thu, 4 Aug 2011, Adam Baker wrote:
On Thursday 04 August 2011, Theodore Kilgore wrote:
As far as I know, /dev/sdx signifies a device which is accessible by
something like the USB mass storage protocols, at the very least. So,
if
On Fri, 5 Aug 2011, Adam Baker wrote:
On Thursday 04 August 2011, Theodore Kilgore wrote:
On Thu, 4 Aug 2011, Adam Baker wrote:
On Thursday 04 August 2011, Theodore Kilgore wrote:
As far as I know, /dev/sdx signifies a device which is accessible by
something like the USB mass
43 matches
Mail list logo
