V4L-DVB Summit Day 3

V4L-DVB Summit Day 3

[Hans Verkuil]

Hi all,

Well, that was another very successful day here in Portland.

I started off presenting the work we did in the past year and our plans for 
the next year during the BoF this morning. It was quite a big crowd and the 
talk was well received.

The presentation is available from my website:

http://www.xs4all.nl/~hverkuil/lpc/bof.odp

The nice thing was that this presentation was hot off the press as it 
presented all the things we discussed in the two preceding days of the summit. 

Two additional presentations from Samsung regarding their SoCs and their 
implementation of a memory pool-like API are also available from my website:

http://www.xs4all.nl/~hverkuil/lpc/Samsung_SoCs.ppt
http://www.xs4all.nl/~hverkuil/lpc/Unified_media_buffers.pdf

Unfortunately I couldn't attend the presentation from Hans de Goede and 
Brandon Philips, so I can't comment on that. It would be great if someone can 
post a report of that presentation (and links to the presentation itself, if 
possible).

During the afternoon we worked on assigning people to the various tasks that 
need to be done.

I made the following list:

- We created a new mc mailinglist: linux-mc@googlegroups.com

This is a temporary mailinglist where we can post and review patches during 
prototyping of the mc API. We don't want to flood the linux-media list with 
those patches since that is already quite high-volume.

The mailinglist should be active, although I couldn't find it yet from 
www.googlegroups.com. I'm not sure if it hasn't shown up yet, or if I did 
something wrong.

- implement sensor v4l2_subdev support (Laurent). We are still missing some 
v4l2_subdev sensor ops for setting up the bus config and data format. Laurent 
will look into implementing those. An RFC for the bus config already exists 
and will function as the basis of this.

- when done, remove the v4l2-int-device API (Nokia, target 2.6.33). It's 
important to finally remove this non-standard API. When we can setup sensors 
properly using subdevs, then Nokia can convert the final two users of this API 
to v4l2_subdev.

- subdev migration omap3:
        - ISP (Laurent)  
        - video decoder (Vaibhav)
        - display (Vaibhav)

These are the initial test implementations for the media controller: 
converting the various parts of the omap3 driver to subdevs and see how these 
can be controller via the mc.

- subdev migration Moorestown (Intel):
        - sensors
        - LED driver
        - video decoder/encoder
        - more...

Intel will do something similar for their Moorestown platform.

- Samsung: investigate V4L2 API and mc concept.

Samsung needs to investigate the V4L2 API and the mc proposal first before 
they can commit to anything.

- HDTV timings API (Murali, 2.6.33). This is an important API that we should 
be able to get into 2.6.33.

- Event handling API (RFC: Laurent, code: Guru Raj, 2.6.33). Ditto. Laurent 
will update the RFC, Guru Raj from Intel will write the code for it (Laurent 
already has a lot on his plate).

- Memory pool API (Laurent, Vaibhav). Laurent and Vaibhav will do the research 
needed for this API.

- Control framework (Hans). In November I hope to finish the control 
framework.

- Media Controller testbed: create device nodes for subdevs and cleanup (Hans)
  (http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-mc). My tree needs updating to 
reflect the discussions during this summit. I hope to do this in two weeks 
from now. It will create a decent starting point for the various mc 
prototyping efforts.

- Associating alsa and video (esp. USB) (Devin). Devin will do more research 
on how to associate alsa and video nodes. In particular for USB webcam 
devices.

- Research a new ioctl that just enums device nodes to get audio/video 
association solved quickly. Will be subset of v4l2_mc_entity struct. (Devin).
Devin raised the valid concern that it will probably take many months before 
the mc and all related ioctls will be implemented. But there is a very urgent 
need for applications to be able to find related alsa/video nodes. A possible 
approach is to create an ioctl for the mc that basically will just enumerate 
device nodes and will give a subset of what the final entity enumeration ioctl 
will return. Just enough to let applications use it to figure out these 
alsa/vbi/video relationships. Devin will do more research into this.

- Userspace libraries for the SoCs (TBD). Not discussed yet is how to create 
the userspace libraries that contain the SoC specific code: should they 
conform to certain requirements? Or is it free-for-all? Should we have a 
central repository for these libraries? It is to early to tell.

We also listed the criteria when to decide that the mc API is ready for 
submission to the v4l-dvb repository:

- Implemented in UVC
- Implemented in ivtv
- Without modifying bttv the code framework should setup workable entities by 
default.
- Implemented in omap3 together with a test userspace library.

These three days clearly showed that there is a lot of interest from SoC 
companies into the mc concept. The interest in these sessions was frankly 
overwhelming.

I would like to thank the Linux Foundation for organizing the LPC and 
arranging for a room for all three days where we could hold our summit 
meetings.

I would also like to thank (in no particular order) Mike Krufky, Steven Toth, 
Andy Walls, Brandon Philips, Hans de Goede and Devin Heitmueller as 
independent v4l-dvb developers. Also Sakari Ailus and Laurent Pinchart 
representing Nokia and Vaibhav Hiremath, Sergio Alberto Aguirre Rodriguez, 
Murali Karicheri and Lajos Molnar from Texas Instruments. And also Marek 
Szyprowski, Tomasz Fujak and Jin-Sung Yang from Samsung. And finally from 
Intel I would like to thank Guru Raj and Xiaolin Zhang.

My apologies if I missed someone, but I think I got all the main players 
participating in these discussions listed.

I hope that in August 2010 during the next LPC in Boston I can proudly present 
the results of this summit. It will be great if we can get all this stuff in 
by that time.

Starting tomorrow I'm off on a one-week vacation in Canada, and I'll try to 
make at least part of that week internet-free, so don't expect to hear much 
from me until I'm back in Oslo 10 days from now.

Oh, and if you're ever in Portland then I can really recommend restaurant 
'Veritable Quandary'. The name may be a bit weird, but the food was great!

Regards,

	Hans

Re: V4L-DVB Summit Day 3

[Guennadi Liakhovetski]

On Fri, 25 Sep 2009, Hans Verkuil wrote:

> - implement sensor v4l2_subdev support (Laurent). We are still missing some 
> v4l2_subdev sensor ops for setting up the bus config and data format. Laurent 
> will look into implementing those. An RFC for the bus config already exists 
> and will function as the basis of this.

Good, obviously, I'm veryinterested in both these APIs, and I hope Laurent 
will have a look at my earlier imagebus proposal and use that API as a 
basis for the data format API. My RFC, probably, didn't cover all possible 
cases, but it should be a reasonable starting point with easy enough 
extensibility. I did get a couple of positive feedbacks regarding that 
API, and I have converted the whole soc-camera stack to it and am working 
on some new drivers with that API. So far I didn't have a single case 
where I would have to amend or extend it.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: V4L-DVB Summit Day 3

[Dongsoo, Nathaniel Kim]

Hi Hans,

On Sat, Sep 26, 2009 at 3:22 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> Hi all,
>
> Well, that was another very successful day here in Portland.
>
> I started off presenting the work we did in the past year and our plans for
> the next year during the BoF this morning. It was quite a big crowd and the
> talk was well received.
>
> The presentation is available from my website:
>
> http://www.xs4all.nl/~hverkuil/lpc/bof.odp
>
> The nice thing was that this presentation was hot off the press as it
> presented all the things we discussed in the two preceding days of the summit.
>
> Two additional presentations from Samsung regarding their SoCs and their
> implementation of a memory pool-like API are also available from my website:
>
> http://www.xs4all.nl/~hverkuil/lpc/Samsung_SoCs.ppt
> http://www.xs4all.nl/~hverkuil/lpc/Unified_media_buffers.pdf
>
> Unfortunately I couldn't attend the presentation from Hans de Goede and
> Brandon Philips, so I can't comment on that. It would be great if someone can
> post a report of that presentation (and links to the presentation itself, if
> possible).
>
> During the afternoon we worked on assigning people to the various tasks that
> need to be done.
>
> I made the following list:
>
> - We created a new mc mailinglist: linux-mc@googlegroups.com
>
> This is a temporary mailinglist where we can post and review patches during
> prototyping of the mc API. We don't want to flood the linux-media list with
> those patches since that is already quite high-volume.
>
> The mailinglist should be active, although I couldn't find it yet from
> www.googlegroups.com. I'm not sure if it hasn't shown up yet, or if I did
> something wrong.
>
> - implement sensor v4l2_subdev support (Laurent). We are still missing some
> v4l2_subdev sensor ops for setting up the bus config and data format. Laurent
> will look into implementing those. An RFC for the bus config already exists
> and will function as the basis of this.
>
> - when done, remove the v4l2-int-device API (Nokia, target 2.6.33). It's
> important to finally remove this non-standard API. When we can setup sensors
> properly using subdevs, then Nokia can convert the final two users of this API
> to v4l2_subdev.
>
> - subdev migration omap3:
>        - ISP (Laurent)
>        - video decoder (Vaibhav)
>        - display (Vaibhav)
>
> These are the initial test implementations for the media controller:
> converting the various parts of the omap3 driver to subdevs and see how these
> can be controller via the mc.
>
> - subdev migration Moorestown (Intel):
>        - sensors
>        - LED driver
>        - video decoder/encoder
>        - more...
>
> Intel will do something similar for their Moorestown platform.
>
> - Samsung: investigate V4L2 API and mc concept.
>
> Samsung needs to investigate the V4L2 API and the mc proposal first before
> they can commit to anything.
>

BTW I just forgot to ask Marek and Tomasz to ask you guys at
mini-summit about can the HDMI device fit into the v4l2 framework.
Because as far as my investigation, I found HDMI interface driver from
Intel not in the v4l2 drivers but in gpu drivers and totally doesn't
seem to be a v4l2 one at all.

As you already know, the new arm based SoC from Samsung has HDMI
interface and I'm very curious about which approach is better one
between v4l2 approach and framebuffer approach. Because that HDMI
interface has a mixer feature just like an overlay feature in
framebuffer devices. It will be nice if someone points me the right
way :)

According to your mail, I suppose that this conference was a
magnificent and important turning point for v4l2. I wished I could
attend the conference but trillions of works were stuck in my queue
:'(
Cheers,

Nate

-- 
=
DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media & Communications R&D Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo.kim@gmail.com
          dongsoo45.kim@samsung.com

Re: V4L-DVB Summit Day 3

[Laurent Pinchart]

Hi Guennadi,

On Saturday 26 September 2009 14:25:07 Guennadi Liakhovetski wrote:
> On Fri, 25 Sep 2009, Hans Verkuil wrote:
> > - implement sensor v4l2_subdev support (Laurent). We are still missing
> > some v4l2_subdev sensor ops for setting up the bus config and data
> > format. Laurent will look into implementing those. An RFC for the bus
> > config already exists and will function as the basis of this.

I volunteered to port the sensor drivers we use with the OMAP3 to v4l2_subdev, 
implementing the missing operations/helpers/whatever on the way, but it 
somehow escaped my mind at the time that it included the bus config and data 
format operations :-)

> Good, obviously, I'm veryinterested in both these APIs, and I hope Laurent
> will have a look at my earlier imagebus proposal and use that API as a
> basis for the data format API. My RFC, probably, didn't cover all possible
> cases, but it should be a reasonable starting point with easy enough
> extensibility. I did get a couple of positive feedbacks regarding that
> API, and I have converted the whole soc-camera stack to it and am working
> on some new drivers with that API. So far I didn't have a single case
> where I would have to amend or extend it.

Your RFC will be used as a starting point (actually more than a starting 
point, as there has been lots of discussions around it already). My plan is to 
reuse what's available in RFCs as-is, port the drivers, see how everything 
shatters to pieces (hopefully it won't :-)), and post RFCs to fix the problems 
if required. You will of course be included in the discussion.

-- 
Regards,

Laurent Pinchart

Re: [Bulk] V4L-DVB Summit Day 3

[CityK]

Hans Verkuil wrote:
> I made the following list:
>
> - We created a new mc mailinglist: linux-mc@googlegroups.com
>
> This is a temporary mailinglist where we can post and review patches during 
> prototyping of the mc API. We don't want to flood the linux-media list with 
> those patches since that is already quite high-volume.
>
> The mailinglist should be active, although I couldn't find it yet from 
> www.googlegroups.com. I'm not sure if it hasn't shown up yet, or if I did 
> something wrong.
>   

I'm scratching my head on this one.  Seems the last thing that is needed
is YET another mailing list.  Further, it
- fractures the development community. 
- persons unaware of the decision, and whom might be interested, would
never find it . i.e. alienation
- disinterested parties can simply hit the delete key and not bother
with the message
- blah blah blah ..

PS.  In regards to yesterday's business announcements, I hope your new
forthcoming overlords are as kind to you as your last

Re: [Bulk] V4L-DVB Summit Day 3

[Markus Rechberger]

On Fri, Oct 2, 2009 at 7:56 PM, CityK <cityk@rogers.com> wrote:
> Hans Verkuil wrote:
>> I made the following list:
>>
>> - We created a new mc mailinglist: linux-mc@googlegroups.com
>>
>> This is a temporary mailinglist where we can post and review patches during
>> prototyping of the mc API. We don't want to flood the linux-media list with
>> those patches since that is already quite high-volume.
>>
>> The mailinglist should be active, although I couldn't find it yet from
>> www.googlegroups.com. I'm not sure if it hasn't shown up yet, or if I did
>> something wrong.
>>
>
> I'm scratching my head on this one.  Seems the last thing that is needed
> is YET another mailing list.  Further, it
> - fractures the development community.

this is what I think too. I'm mainly interested in keeping up
compatibility with that framework
The traffic on this mailinglist is rather small and it should be ok to
mix up developer mails
with a few support mails (whereas people usually use to CC anyone who
might be involved anyway).

> - persons unaware of the decision, and whom might be interested, would
> never find it . i.e. alienation

if you try to send an email as adviced to that googlemail mailinglist
you'll just get an email back that it doesn't work :-)

nothing else to write about it I totally agree.

One question I have though, what is the impact to the existing API,
will they start to require that MC interface?
TI hardware is rather specialized and most other devices will not need
any of those changes, I don't see the benefit
of bloating up the API for devices which already work fine, for simple
devices it should better remain simple.
(This question is mainly because we also maintain our own player which
supports the v4l2/dvbV(3/5) API, but the
driver should still support legacy applications in the future)

Best Regards,
Markus