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-2011(a)linuxtv.org
I'll also be updating the event page at:
http://www.linuxtv.org/events.php
Over the one-year period, we had 242 developers contributing to the
subsystem. Thank you all for that! Unfortunately, the space there is
limited, and we can't affort to have all developers there.
Due to that some criteria needed to be applied to create a short list
of people that were invited today to participate.
The main criteria were to select the developers that did significant
contributions for the media subsystem over the last 1 year period,
measured in terms of number of commits and changed lines to the kernel
drivers/media tree.
As the used criteria were the number of kernel patches, userspace-only
developers weren't included on the invitations. It would be great to
have there open source application developers as well, in order to allow
us to tune what's needed from applications point of view.
So, if you're leading the development of some V4L and/or DVB open-source
application and wants to be there, or you think you can give good
contributions for helping to improve the subsystem, please feel free
to send us an email.
With regards to the themes, we're received, up to now, the following
proposals:
---------------------------------------------------------+----------------------
THEME | Proposed-by:
---------------------------------------------------------+----------------------
Buffer management: snapshot mode | Guennadi
Rotation in webcams in tablets while streaming is active | Hans de Goede
V4L2 Spec – ambiguities fix | Hans Verkuil
V4L2 compliance test results | Hans Verkuil
Media Controller presentation (probably for Wed, 25) | Laurent Pinchart
Workshop summary presentation on Wed, 25 | Mauro Carvalho Chehab
---------------------------------------------------------+----------------------
>From my side, I also have the following proposals:
1) DVB API consistency - what to do with the audio and video DVB API's
that conflict with V4L2 and (somewhat) with ALSA?
2) Multi FE support - How should we handle a frontend with multiple
delivery systems like DRX-K frontend?
3) videobuf2 - migration plans for legacy drivers
4) NEC IR decoding - how should we handle 32, 24, and 16 bit protocol
variations?
Even if you won't be there, please feel free to propose themes for
discussion, in order to help us to improve even more the subsystem.
Thank you!
Mauro
Hi Mauro,
I am not be able to attend the 2011 Media subsystem workshop in Prague.
Hopefully this will free up a spot for someone else who wishes to
attend.
Regards,
Andy
(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 <mchehab(a)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 stored pictures,
> > > which were taken in standalone (iow not connected to usb) stillcam mode.
> > >
> > > This API does not need to be terribly complex. AFAIK all of the currently
> > > supported dual cam cameras don't have filenames only picture numbers,
> > > so the API could consist of a simple, get highest picture nr, is picture
> > > X present (some slots may contain deleted pictures), get picture X,
> > > delete picture X, delete all API.
> >
> > That sounds to work. I would map it on a way close to the controls API
> > (or like the DVB FE_[GET|SET]_PROPERTY API), as this would make easier to expand
> > it in the future, if we start to see webcams with file names or other things
> > like that.
>
> I did not follow all the thread, but I was wondering about an other
> solution: what about offering both USB mass storage and webcam accesses?
>
> When a dual-mode webcam is plugged in, the driver creates two devices,
> the video device /dev/videox and the volume /dev/sdx. When the webcam is
> opened, the volume cannot be mounted. When the volume is mounted, the
> webcam cannot be opened. There is no need for a specific API. As Mauro
> said:
>
> > For those, we may eventually need some sort of locking between
> > the USB storage and V4L.
>
> That's all. By where am I wrong?
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.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
