Tentative agenda for Helsinki mini-summit

Tentative agenda for Helsinki mini-summit

[Hans Verkuil]

Hi all,

This is a tentative agenda for the Helsinki mini-summit on June 14-16.

Please reply to this thread if you have comments or want to add topics.

The overall layout of the summit is to use the first day to go through all
topics and either come to a conclusion quickly for the 'simple' topics, or
discuss enough so that everyone understands the problem for the more complex
issues.

The second day will be used for in-depth discussions on those complex topics
and on the third day we will go through all topics again and translate the
discussions into something concrete like a time-line, action items, etc.

We have a lot to discuss, so we may have to split the second day into two
'tracks', each discussing different topics. I hope it is not needed, but I
fear we may have no choice. If we do split up, then one track will touch on
the videobuf-related topics and the other on the remaining topics.

The first day will also feature a few short presentations on various topics.
Presentations shouldn't be longer than, say, 10 minutes. These presentations
are meant to get everyone up to speed quickly.

After each topic I've put the names of the main developers active in that area.
If you see your name, then make sure you know the status of that topic so you
can explain it to everyone else. If I think it warrants a presentation, then I
will mention that. Of course, if you disagree, or want/don't want to do a
presentation then just say so. It's a tentative agenda only.

The topics below are in no particular order except for the first one. I am
very pleased that Qualcomm has joined this project so I think it would be
nice to start the meeting off with a presentation on their HW architecture.

1) Presentation on the Qualcomm video hw architecture. Most of us have no
   experience with Qualcomm hardware, so I've asked Jeff Zhong to give a short
   overview of their video hardware.

2) Removal of V4L1: status of driver conversion in the kernel, status of
   moving v4l1->v4l2 conversion into libv4l1. What needs to be done, when
   will it be done and who will do it. Driver conversion: Hans Verkuil,
   libv4l1 conversion: Hans de Goede.

3) videobuf/videobuf2: what are the shortcomings, what are the requirements for
   a 'proper' videobuf implementation, can the existing videobuf be fixed or do
   we need a videobuf2. If the latter, what would be needed to convert existing
   drivers over to a videobuf2. Laurent Pinchart and Pawel Osciak. This I'm sure
   requires a presentation.

4) Multi-planar support. Pawel Osciak.

5) Media Controller Roadmap. Laurent Pinchart. This probably warrants a short
   presentation.

6) TO DO list regarding V4L2 core framework including the new control framework.
   Hans Verkuil. Will be a presentation.

7) Status of the Texas Instruments drivers: omapX (Hiremath Vaibhav) and DMxxxx
   (Sergio Aguirre). Probably should be a short presentation.

8) soc-camera status. Particularly with regards to the remaining soc-camera
   dependencies in sensor drivers. Guennadi Liakhovetski.

9) Driver compliance. We need a framework for V4L2 driver compliance. Hans
   Verkuil.

10) Discuss list of 'reference' programs to test against. Mauro?

11) Adopting old V4L1 programs and converting to V4L2. Hans de Goede?

12) Status of intel drivers. Xiaolin Zhang.

It is my understanding that we will also have X11 and gstreamer experts on hand.
Topics relating to that are welcome.

During the memory handling brainstorming session earlier this year we also
touched on creating some sort of a generic buffer model allowing for easy
exchange between v4l buffers, framebuffers, texture buffers, etc. It is my
opinion that we should not discuss this in Helsinki. The list of topics is
already quite long and I think it is too early to start working on that. We
probably need another brainstorming session first in order to come up with
a reasonable proposal.

Comments? Topics I missed?

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco

Re: Tentative agenda for Helsinki mini-summit

[Mauro Carvalho Chehab]

Hans Verkuil wrote:
> Hi all,
> 
> This is a tentative agenda for the Helsinki mini-summit on June 14-16.
> 
> Please reply to this thread if you have comments or want to add topics.
> 
> The overall layout of the summit is to use the first day to go through all
> topics and either come to a conclusion quickly for the 'simple' topics, or
> discuss enough so that everyone understands the problem for the more complex
> issues.
> 
> The second day will be used for in-depth discussions on those complex topics
> and on the third day we will go through all topics again and translate the
> discussions into something concrete like a time-line, action items, etc.
> 
> We have a lot to discuss, so we may have to split the second day into two
> 'tracks', each discussing different topics. I hope it is not needed, but I
> fear we may have no choice. If we do split up, then one track will touch on
> the videobuf-related topics and the other on the remaining topics.
> 
> The first day will also feature a few short presentations on various topics.
> Presentations shouldn't be longer than, say, 10 minutes. These presentations
> are meant to get everyone up to speed quickly.
> 
> After each topic I've put the names of the main developers active in that area.
> If you see your name, then make sure you know the status of that topic so you
> can explain it to everyone else. If I think it warrants a presentation, then I
> will mention that. Of course, if you disagree, or want/don't want to do a
> presentation then just say so. It's a tentative agenda only.
> 
> The topics below are in no particular order except for the first one. I am
> very pleased that Qualcomm has joined this project so I think it would be
> nice to start the meeting off with a presentation on their HW architecture.
> 
> 1) Presentation on the Qualcomm video hw architecture. Most of us have no
>    experience with Qualcomm hardware, so I've asked Jeff Zhong to give a short
>    overview of their video hardware.
> 
> 2) Removal of V4L1: status of driver conversion in the kernel, status of
>    moving v4l1->v4l2 conversion into libv4l1. What needs to be done, when
>    will it be done and who will do it. Driver conversion: Hans Verkuil,
>    libv4l1 conversion: Hans de Goede.
> 
> 3) videobuf/videobuf2: what are the shortcomings, what are the requirements for
>    a 'proper' videobuf implementation, can the existing videobuf be fixed or do
>    we need a videobuf2. If the latter, what would be needed to convert existing
>    drivers over to a videobuf2. Laurent Pinchart and Pawel Osciak. This I'm sure
>    requires a presentation.
> 
> 4) Multi-planar support. Pawel Osciak.
> 
> 5) Media Controller Roadmap. Laurent Pinchart. This probably warrants a short
>    presentation.
> 
> 6) TO DO list regarding V4L2 core framework including the new control framework.
>    Hans Verkuil. Will be a presentation.
> 
> 7) Status of the Texas Instruments drivers: omapX (Hiremath Vaibhav) and DMxxxx
>    (Sergio Aguirre). Probably should be a short presentation.
> 
> 8) soc-camera status. Particularly with regards to the remaining soc-camera
>    dependencies in sensor drivers. Guennadi Liakhovetski.
> 
> 9) Driver compliance. We need a framework for V4L2 driver compliance. Hans
>    Verkuil.
> 
> 10) Discuss list of 'reference' programs to test against. Mauro?

I'm ok with the theme. I don't think we need a presentation for it, but to open a
round table to discuss the reference applications that will be considered when
testing media drivers.

> 11) Adopting old V4L1 programs and converting to V4L2. Hans de Goede?
> 
> 12) Status of intel drivers. Xiaolin Zhang.

> It is my understanding that we will also have X11 and gstreamer experts on hand.
> Topics relating to that are welcome.
> 
> During the memory handling brainstorming session earlier this year we also
> touched on creating some sort of a generic buffer model allowing for easy
> exchange between v4l buffers, framebuffers, texture buffers, etc. It is my
> opinion that we should not discuss this in Helsinki. The list of topics is
> already quite long and I think it is too early to start working on that. We
> probably need another brainstorming session first in order to come up with
> a reasonable proposal.
> 
> Comments? Topics I missed?
> 

I'd like to add another topic: Remote Controllers. I propose to do a short presentation
on this theme, showing how the new RC subsystem was conceived and discussing a little bit
about possible evolutions of it. One of the things I'm interested on getting feedback is
about how Linux embedded devices are currently handing IR. All Linux TV sets, set top boxes
and other device types have IR, but I've seen no contributions from embedded developers at 
RC code. So, after a short presentation, I think we should reserve some time for discussions.

> Regards,
> 
> 	Hans
> 


-- 

Cheers,
Mauro

Re: Tentative agenda for Helsinki mini-summit

[Laurent Pinchart]

Hi Mauro,

On Sunday 23 May 2010 14:21:46 Mauro Carvalho Chehab wrote:
> Hans Verkuil wrote:

[snip]

> > Comments? Topics I missed?
> 
> I'd like to add another topic: Remote Controllers. I propose to do a short
> presentation on this theme, showing how the new RC subsystem was conceived
> and discussing a little bit about possible evolutions of it. One of the
> things I'm interested on getting feedback is about how Linux embedded
> devices are currently handing IR. All Linux TV sets, set top boxes and
> other device types have IR, but I've seen no contributions from embedded
> developers at RC code. So, after a short presentation, I think we should
> reserve some time for discussions.

I have no experience at all with IR in V4L2, and I think that's true for the 
other developers at Nokia. Will there be someone at the mini-summit who has 
experience or is interested in the topic ?

-- 
Regards,

Laurent Pinchart

Re: Tentative agenda for Helsinki mini-summit

[Guennadi Liakhovetski]

On Sun, 23 May 2010, Hans Verkuil wrote:

> Hi all,
> 
> This is a tentative agenda for the Helsinki mini-summit on June 14-16.
> 
> Please reply to this thread if you have comments or want to add topics.

[snip]

> 8) soc-camera status. Particularly with regards to the remaining soc-camera
>    dependencies in sensor drivers. Guennadi Liakhovetski.

Don't think a formal presentation is needed, but I can tell a couple of 
words to clarify the current status a bit.

> Comments? Topics I missed?

No idea whether this is a worthy and suitable topic for this meeting, but:

V4L(2) video output vs. framebuffer.

Problem: Currently the standard way to provide graphical output on various 
(embedded) displays like LCDs is to use a framebuffer driver. The 
interface is well supported and widely adopted in the user-space, many 
applications, including the X-server, various libraries like directfb, 
gstreamer, mplayer, etc. In the kernel space, however, the subsystem has a 
number of problems. It is unmaintained. The infrastructure is not being 
further developed, every specific hardware driver is being supported by 
the respective architecture community. But as video output hardware 
evolves, more complex displays and buses appear and have to be supported, 
the subsystem shows its aging. For example, there is currently no way to 
write reusable across multiple platforms display drivers.

OTOH V4L2 has a standard vodeo output driver support, it is not very 
widely used, in the userspace I know only of gstreamer, that somehow 
supports video-output v4l2 devices in latest versions. But, being a part 
of the v4l2 subsystem, these drivers already now can take a full advantage 
of all v4l2 APIs, including the v4l2-subdev API for the driver reuse.

So, how can we help graphics driver developers on the one hand by 
providing them with a capable driver framework (v4l2) and on the other 
hand by simplifying the task of interfacing to the user-space?

How about a v4l2-output - fbdev translation layer? You write a v4l2-output 
driver and get a framebuffer device free of charge... TBH, I haven't given 
this too much of a thought, but so far I don't see anything that would 
make this impossible in principle. The video buffer management is quite 
different between the two systems, but maybe we can teach video-output 
drivers to work with just one buffer too? Anyway, feel free to tell me why 
this is an absolutely impossible / impractical idea;)

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

RE: Tentative agenda for Helsinki mini-summit

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Guennadi Liakhovetski [mailto:g.liakhovetski@gmx.de]
> Sent: Sunday, May 23, 2010 11:33 PM
> To: Hans Verkuil
> Cc: Linux Media Mailing List; Zhong, Jeff; Laurent Pinchart; Pawel Osciak;
> Zhang, Xiaolin; Aguirre, Sergio; Hiremath, Vaibhav; Hans de Goede; Mauro
> Carvalho Chehab
> Subject: Re: Tentative agenda for Helsinki mini-summit
> 
> On Sun, 23 May 2010, Hans Verkuil wrote:
> 
> > Hi all,
> >
> > This is a tentative agenda for the Helsinki mini-summit on June 14-16.
> >
> > Please reply to this thread if you have comments or want to add topics.
> 
> [snip]
> 
> > 8) soc-camera status. Particularly with regards to the remaining soc-
> camera
> >    dependencies in sensor drivers. Guennadi Liakhovetski.
> 
> Don't think a formal presentation is needed, but I can tell a couple of
> words to clarify the current status a bit.
> 
> > Comments? Topics I missed?
> 
> No idea whether this is a worthy and suitable topic for this meeting, but:
> 
> V4L(2) video output vs. framebuffer.
> 
> Problem: Currently the standard way to provide graphical output on various
> (embedded) displays like LCDs is to use a framebuffer driver. The
> interface is well supported and widely adopted in the user-space, many
> applications, including the X-server, various libraries like directfb,
> gstreamer, mplayer, etc. In the kernel space, however, the subsystem has a
> number of problems. It is unmaintained. 
[Hiremath, Vaibhav] Unfortunately yes it is true.

> The infrastructure is not being
> further developed, every specific hardware driver is being supported by
> the respective architecture community. But as video output hardware
> evolves, more complex displays and buses appear and have to be supported,
> the subsystem shows its aging. For example, there is currently no way to
> write reusable across multiple platforms display drivers.
> 
[Hiremath, Vaibhav] Up to certain extent yes you are correct.

> OTOH V4L2 has a standard vodeo output driver support, it is not very
> widely used, in the userspace I know only of gstreamer, that somehow
> supports video-output v4l2 devices in latest versions. But, being a part
> of the v4l2 subsystem, these drivers already now can take a full advantage
> of all v4l2 APIs, including the v4l2-subdev API for the driver reuse.
> 
> So, how can we help graphics driver developers on the one hand by
> providing them with a capable driver framework (v4l2) and on the other
> hand by simplifying the task of interfacing to the user-space?
> 
[Hiremath, Vaibhav] I think this is really complex question which requires healthy discussion over list.


> How about a v4l2-output - fbdev translation layer? You write a v4l2-output
> driver and get a framebuffer device free of charge... 
[Hiremath, Vaibhav] It would be nice if you put some more details/thoughts here for better understanding of what exactly you are thinking/proposing.

> TBH, I haven't given
> this too much of a thought, but so far I don't see anything that would
> make this impossible in principle. The video buffer management is quite
> different between the two systems, but maybe we can teach video-output
> drivers to work with just one buffer too? 
[Hiremath, Vaibhav] I believe V4L2 buf won't limit you to do this. Atleast in case of OMAP v4L2 display driver we are sticking to last buffer if application fails to queue one. So for me this is single buffer keeps on displaying unless application queue next buffer. 


> Anyway, feel free to tell me why
> this is an absolutely impossible / impractical idea;)
> 
[Hiremath, Vaibhav] If I understanding correctly you are trying to propose something like,

Without changing Fbdev interface to user space application, create translation layers which will allow driver developer to write driver under V4L2 framework providing /dev/fbx but using V4L2 API/framework.

Thanks,
Vaibhav

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

RE: Tentative agenda for Helsinki mini-summit

[Pawel Osciak]

Hi,

>Guennadi Liakhovetski wrote:
>
>No idea whether this is a worthy and suitable topic for this meeting, but:
>
>V4L(2) video output vs. framebuffer.
>
>How about a v4l2-output - fbdev translation layer? You write a v4l2-output
>driver and get a framebuffer device free of charge... TBH, I haven't given
>this too much of a thought, but so far I don't see anything that would
>make this impossible in principle. The video buffer management is quite
>different between the two systems, but maybe we can teach video-output
>drivers to work with just one buffer too? Anyway, feel free to tell me why
>this is an absolutely impossible / impractical idea;)

We also use v4l2-outputs for our display interfaces and for that we have
v4l2-subdevices in a framebuffer driver. Although we have had no need for
such a translation layer per se up to now, the idea seems interesting.

I would definitely be interested in a general discussion about framebuffer
driver - v4l2 output device interoperability though and can share our
experience in this field.

Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland R&D Center

RE: Tentative agenda for Helsinki mini-summit

[Guennadi Liakhovetski]

On Thu, 27 May 2010, Pawel Osciak wrote:

> Hi,
> 
> >Guennadi Liakhovetski wrote:
> >
> >No idea whether this is a worthy and suitable topic for this meeting, but:
> >
> >V4L(2) video output vs. framebuffer.
> >
> >How about a v4l2-output - fbdev translation layer? You write a v4l2-output
> >driver and get a framebuffer device free of charge... TBH, I haven't given
> >this too much of a thought, but so far I don't see anything that would
> >make this impossible in principle. The video buffer management is quite
> >different between the two systems, but maybe we can teach video-output
> >drivers to work with just one buffer too? Anyway, feel free to tell me why
> >this is an absolutely impossible / impractical idea;)
> 
> We also use v4l2-outputs for our display interfaces and for that we have
> v4l2-subdevices in a framebuffer driver. Although we have had no need for
> such a translation layer per se up to now, the idea seems interesting.

Interesting, but sorry, don't quite understand "we use v4l2-outputs" and 
"in a framebuffer driver" - so, is it a framebuffer (/dev/fbX) or a v4l2 
output device driver or both? Which driver is this? Is it already in the 
mainline?

> I would definitely be interested in a general discussion about framebuffer
> driver - v4l2 output device interoperability though and can share our
> experience in this field.

Yes, please, do, it would be very much appreciated!

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

RE: Tentative agenda for Helsinki mini-summit

[Pawel Osciak]

>Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote:
>On Thu, 27 May 2010, Pawel Osciak wrote:
>
>> Hi,
>>
>> >Guennadi Liakhovetski wrote:
>> >
>> >No idea whether this is a worthy and suitable topic for this meeting, but:
>> >
>> >V4L(2) video output vs. framebuffer.
>> >
>> >How about a v4l2-output - fbdev translation layer? You write a v4l2-output
>> >driver and get a framebuffer device free of charge... TBH, I haven't given
>> >this too much of a thought, but so far I don't see anything that would
>> >make this impossible in principle. The video buffer management is quite
>> >different between the two systems, but maybe we can teach video-output
>> >drivers to work with just one buffer too? Anyway, feel free to tell me why
>> >this is an absolutely impossible / impractical idea;)
>>
>> We also use v4l2-outputs for our display interfaces and for that we have
>> v4l2-subdevices in a framebuffer driver. Although we have had no need for
>> such a translation layer per se up to now, the idea seems interesting.
>
>Interesting, but sorry, don't quite understand "we use v4l2-outputs" and
>"in a framebuffer driver" - so, is it a framebuffer (/dev/fbX) or a v4l2
>output device driver or both? Which driver is this? Is it already in the
>mainline?
>

It's the (mostly) standard s3c-fb driver with a v4l2-subdev video interface
added. A separate v4l2 output device driver uses that interface to communicate
with the framebuffer driver, as some setup is required on both parts.

Those operations cannot be performed from userspace as they have to be
synchronized in interrupts.

Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland R&D Center

Re: Tentative agenda for Helsinki mini-summit

[Hans Verkuil]

On Sunday 23 May 2010 20:02:59 Guennadi Liakhovetski wrote:
> On Sun, 23 May 2010, Hans Verkuil wrote:
> 
> > Hi all,
> > 
> > This is a tentative agenda for the Helsinki mini-summit on June 14-16.
> > 
> > Please reply to this thread if you have comments or want to add topics.
> 
> [snip]
> 
> > 8) soc-camera status. Particularly with regards to the remaining soc-camera
> >    dependencies in sensor drivers. Guennadi Liakhovetski.
> 
> Don't think a formal presentation is needed, but I can tell a couple of 
> words to clarify the current status a bit.
> 
> > Comments? Topics I missed?
> 
> No idea whether this is a worthy and suitable topic for this meeting, but:
> 
> V4L(2) video output vs. framebuffer.
> 
> Problem: Currently the standard way to provide graphical output on various 
> (embedded) displays like LCDs is to use a framebuffer driver. The 
> interface is well supported and widely adopted in the user-space, many 
> applications, including the X-server, various libraries like directfb, 
> gstreamer, mplayer, etc. In the kernel space, however, the subsystem has a 
> number of problems. It is unmaintained. The infrastructure is not being 
> further developed, every specific hardware driver is being supported by 
> the respective architecture community. But as video output hardware 
> evolves, more complex displays and buses appear and have to be supported, 
> the subsystem shows its aging. For example, there is currently no way to 
> write reusable across multiple platforms display drivers.
> 
> OTOH V4L2 has a standard vodeo output driver support, it is not very 
> widely used, in the userspace I know only of gstreamer, that somehow 
> supports video-output v4l2 devices in latest versions. But, being a part 
> of the v4l2 subsystem, these drivers already now can take a full advantage 
> of all v4l2 APIs, including the v4l2-subdev API for the driver reuse.
> 
> So, how can we help graphics driver developers on the one hand by 
> providing them with a capable driver framework (v4l2) and on the other 
> hand by simplifying the task of interfacing to the user-space?
> 
> How about a v4l2-output - fbdev translation layer? You write a v4l2-output 
> driver and get a framebuffer device free of charge... TBH, I haven't given 
> this too much of a thought, but so far I don't see anything that would 
> make this impossible in principle. The video buffer management is quite 
> different between the two systems, but maybe we can teach video-output 
> drivers to work with just one buffer too? Anyway, feel free to tell me why 
> this is an absolutely impossible / impractical idea;)

I've added this to the agenda. I think this probably doesn't need a presentation
but will be more an open discussion.

I also think this is a very interesting topic to discuss more in-depth on
Tuesday.

Sakari, does Nokia have any framebuffer experts that might be interested in
discussing this as well on Tuesday?

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco

Re: Tentative agenda for Helsinki mini-summit

[Laurent Pinchart]

Hi Hans,

On Sunday 23 May 2010 12:36:48 Hans Verkuil wrote:
> Hi all,
> 
> This is a tentative agenda for the Helsinki mini-summit on June 14-16.
> 
> Please reply to this thread if you have comments or want to add topics.
> 
> The overall layout of the summit is to use the first day to go through all
> topics and either come to a conclusion quickly for the 'simple' topics, or
> discuss enough so that everyone understands the problem for the more
> complex issues.
> 
> The second day will be used for in-depth discussions on those complex
> topics and on the third day we will go through all topics again and
> translate the discussions into something concrete like a time-line, action
> items, etc.
> 
> We have a lot to discuss, so we may have to split the second day into two
> 'tracks', each discussing different topics. I hope it is not needed, but I
> fear we may have no choice. If we do split up, then one track will touch on
> the videobuf-related topics and the other on the remaining topics.
> 
> The first day will also feature a few short presentations on various
> topics. Presentations shouldn't be longer than, say, 10 minutes. These
> presentations are meant to get everyone up to speed quickly.
> 
> After each topic I've put the names of the main developers active in that
> area. If you see your name, then make sure you know the status of that
> topic so you can explain it to everyone else. If I think it warrants a
> presentation, then I will mention that. Of course, if you disagree, or
> want/don't want to do a presentation then just say so. It's a tentative
> agenda only.
> 
> The topics below are in no particular order except for the first one. I am
> very pleased that Qualcomm has joined this project so I think it would be
> nice to start the meeting off with a presentation on their HW architecture.
> 
> 1) Presentation on the Qualcomm video hw architecture. Most of us have no
>    experience with Qualcomm hardware, so I've asked Jeff Zhong to give a
> short overview of their video hardware.

Generic comment about platform overview presentations: please skip the small 
details (we don't need a list of registers :-)), but make sure the overall 
architecture is properly explained. A functional block diagram is very 
helpful, and platform-specific features or restrictions should be explained 
where useful (such as requirements on memory types, hardware ability to run 
several things in parallel, status of the current driver if any, ...).

> 2) Removal of V4L1: status of driver conversion in the kernel, status of
>    moving v4l1->v4l2 conversion into libv4l1. What needs to be done, when
>    will it be done and who will do it. Driver conversion: Hans Verkuil,
>    libv4l1 conversion: Hans de Goede.
> 
> 3) videobuf/videobuf2: what are the shortcomings, what are the requirements
> for a 'proper' videobuf implementation, can the existing videobuf be fixed
> or do we need a videobuf2. If the latter, what would be needed to convert
> existing drivers over to a videobuf2. Laurent Pinchart and Pawel Osciak.
> This I'm sure requires a presentation.

I will prepare a presentation on the current state of videobuf, highlighting 
the issues. I can also present the OMAP3 ISP video buffers handling code that 
I wrote to replace videobuf in that particular driver.

> 4) Multi-planar support. Pawel Osciak.
> 
> 5) Media Controller Roadmap. Laurent Pinchart. This probably warrants a
> short presentation.

There will be a presentation of the media controller concepts (to get 
everybody up to date) and on the current state of the implementation. I can 
also present our TODO list, but a proper roadmap is probably something we 
should discuss all together.

> 6) TO DO list regarding V4L2 core framework including the new control
> framework. Hans Verkuil. Will be a presentation.
> 
> 7) Status of the Texas Instruments drivers: omapX (Hiremath Vaibhav) and
> DMxxxx (Sergio Aguirre). Probably should be a short presentation.

For the OMAP3 platform I (or maybe Sakari :-)) can explain the status of the 
driver.

> 8) soc-camera status. Particularly with regards to the remaining soc-camera
>    dependencies in sensor drivers. Guennadi Liakhovetski.
> 
> 9) Driver compliance. We need a framework for V4L2 driver compliance. Hans
>    Verkuil.
> 
> 10) Discuss list of 'reference' programs to test against. Mauro?
> 
> 11) Adopting old V4L1 programs and converting to V4L2. Hans de Goede?
> 
> 12) Status of intel drivers. Xiaolin Zhang.
> 
> It is my understanding that we will also have X11 and gstreamer experts on
> hand. Topics relating to that are welcome.
> 
> During the memory handling brainstorming session earlier this year we also
> touched on creating some sort of a generic buffer model allowing for easy
> exchange between v4l buffers, framebuffers, texture buffers, etc. It is my
> opinion that we should not discuss this in Helsinki. The list of topics is
> already quite long and I think it is too early to start working on that. We
> probably need another brainstorming session first in order to come up with
> a reasonable proposal.
>
> Comments? Topics I missed?

-- 
Regards,

Laurent Pinchart

RE: Tentative agenda for Helsinki mini-summit

[Pawel Osciak]

Hi Hans,

thank you for your work on this!

>Hans Verkuil wrote:

>3) videobuf/videobuf2: what are the shortcomings, what are the requirements
>for a 'proper' videobuf implementation, can the existing videobuf be fixed or
>do we need a videobuf2. If the latter, what would be needed to convert
>existing drivers over to a videobuf2. Laurent Pinchart and Pawel Osciak. This I'm
>sure requires a presentation.

As Laurent volunteered to prepare the "videobuf problems" presentation, I will
hopefully make it before the summit with an initial (general) design for the new
videobuf2 - requirements, API, things like that. So I'm thinking about a short
presentation on this. What do you think?

>4) Multi-planar support. Pawel Osciak.

Yes. Will provide a short status update. Is a presentation of the whole concept
required? If so, I can conduct one as well.

>9) Driver compliance. We need a framework for V4L2 driver compliance. Hans
>   Verkuil.

I am very interested in this!

>10) Discuss list of 'reference' programs to test against. Mauro?
>

Ditto.

>During the memory handling brainstorming session earlier this year we also
>touched on creating some sort of a generic buffer model allowing for easy
>exchange between v4l buffers, framebuffers, texture buffers, etc. It is my
>opinion that we should not discuss this in Helsinki. The list of topics is
>already quite long and I think it is too early to start working on that. We
>probably need another brainstorming session first in order to come up with
>a reasonable proposal.

I agree.

>Comments? Topics I missed?

It would be great to touch on the following subjects if we find some time
(and if people would be interested, I had little feedback on the list):

1) Custom/pluggable allocators
As most of us are aware there are important problems with memory allocation
in videobuf that most of us have already faced.
For those unfamiliar with the topic, please see my recent RFC:
http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/19581

I'd like to provide a design of an API:
* for videobuf that would allow drivers to plug-in their own memory allocation
  routines,
* future-proof enough to be usable with videobuf2 as well.

Hoping for a (short-ish) discussion on that.

2) Out-of-order buffer dequeuing and per-buffer wait queues in videobuf. See:
RFC: http://www.mail-archive.com/linux-media@vger.kernel.org/msg17319.html
Patches: http://www.mail-archive.com/linux-media@vger.kernel.org/msg17886.html


Please let me know what you think. Thanks!

Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland R&D Center

Re: Tentative agenda for Helsinki mini-summit

[Hans Verkuil]

On Wednesday 26 May 2010 17:46:16 Pawel Osciak wrote:
> Hi Hans,
> 
> thank you for your work on this!
> 
> >Hans Verkuil wrote:
> 
> >3) videobuf/videobuf2: what are the shortcomings, what are the requirements
> >for a 'proper' videobuf implementation, can the existing videobuf be fixed or
> >do we need a videobuf2. If the latter, what would be needed to convert
> >existing drivers over to a videobuf2. Laurent Pinchart and Pawel Osciak. This I'm
> >sure requires a presentation.
> 
> As Laurent volunteered to prepare the "videobuf problems" presentation, I will
> hopefully make it before the summit with an initial (general) design for the new
> videobuf2 - requirements, API, things like that. So I'm thinking about a short
> presentation on this. What do you think?

Yes please!

> >4) Multi-planar support. Pawel Osciak.
> 
> Yes. Will provide a short status update. Is a presentation of the whole concept
> required? If so, I can conduct one as well.

A presentation for this is not necessary, I think.
 
> >9) Driver compliance. We need a framework for V4L2 driver compliance. Hans
> >   Verkuil.
> 
> I am very interested in this!
> 
> >10) Discuss list of 'reference' programs to test against. Mauro?
> >
> 
> Ditto.
> 
> >During the memory handling brainstorming session earlier this year we also
> >touched on creating some sort of a generic buffer model allowing for easy
> >exchange between v4l buffers, framebuffers, texture buffers, etc. It is my
> >opinion that we should not discuss this in Helsinki. The list of topics is
> >already quite long and I think it is too early to start working on that. We
> >probably need another brainstorming session first in order to come up with
> >a reasonable proposal.
> 
> I agree.
> 
> >Comments? Topics I missed?
> 
> It would be great to touch on the following subjects if we find some time
> (and if people would be interested, I had little feedback on the list):
> 
> 1) Custom/pluggable allocators
> As most of us are aware there are important problems with memory allocation
> in videobuf that most of us have already faced.
> For those unfamiliar with the topic, please see my recent RFC:
> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/19581
> 
> I'd like to provide a design of an API:
> * for videobuf that would allow drivers to plug-in their own memory allocation
>   routines,
> * future-proof enough to be usable with videobuf2 as well.
> 
> Hoping for a (short-ish) discussion on that.
> 
> 2) Out-of-order buffer dequeuing and per-buffer wait queues in videobuf. See:
> RFC: http://www.mail-archive.com/linux-media@vger.kernel.org/msg17319.html
> Patches: http://www.mail-archive.com/linux-media@vger.kernel.org/msg17886.html
> 
> 
> Please let me know what you think. Thanks!

These two items should probably be folded into the videobuf presentations.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco

Re: Tentative agenda for Helsinki mini-summit

[Hans Verkuil]

On Wednesday 26 May 2010 17:46:16 Pawel Osciak wrote:
> Hi Hans,
> 
> thank you for your work on this!
> 
> >Hans Verkuil wrote:
> 
> >3) videobuf/videobuf2: what are the shortcomings, what are the requirements
> >for a 'proper' videobuf implementation, can the existing videobuf be fixed or
> >do we need a videobuf2. If the latter, what would be needed to convert
> >existing drivers over to a videobuf2. Laurent Pinchart and Pawel Osciak. This I'm
> >sure requires a presentation.
> 
> As Laurent volunteered to prepare the "videobuf problems" presentation, I will
> hopefully make it before the summit with an initial (general) design for the new
> videobuf2 - requirements, API, things like that. So I'm thinking about a short
> presentation on this. What do you think?

That's OK.

> >4) Multi-planar support. Pawel Osciak.
> 
> Yes. Will provide a short status update. Is a presentation of the whole concept
> required? If so, I can conduct one as well.

I don't think a presentation is required.

> >9) Driver compliance. We need a framework for V4L2 driver compliance. Hans
> >   Verkuil.
> 
> I am very interested in this!
> 
> >10) Discuss list of 'reference' programs to test against. Mauro?
> >
> 
> Ditto.
> 
> >During the memory handling brainstorming session earlier this year we also
> >touched on creating some sort of a generic buffer model allowing for easy
> >exchange between v4l buffers, framebuffers, texture buffers, etc. It is my
> >opinion that we should not discuss this in Helsinki. The list of topics is
> >already quite long and I think it is too early to start working on that. We
> >probably need another brainstorming session first in order to come up with
> >a reasonable proposal.
> 
> I agree.
> 
> >Comments? Topics I missed?
> 
> It would be great to touch on the following subjects if we find some time
> (and if people would be interested, I had little feedback on the list):
> 
> 1) Custom/pluggable allocators
> As most of us are aware there are important problems with memory allocation
> in videobuf that most of us have already faced.
> For those unfamiliar with the topic, please see my recent RFC:
> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/19581
> 
> I'd like to provide a design of an API:
> * for videobuf that would allow drivers to plug-in their own memory allocation
>   routines,
> * future-proof enough to be usable with videobuf2 as well.
> 
> Hoping for a (short-ish) discussion on that.
> 
> 2) Out-of-order buffer dequeuing and per-buffer wait queues in videobuf. See:
> RFC: http://www.mail-archive.com/linux-media@vger.kernel.org/msg17319.html
> Patches: http://www.mail-archive.com/linux-media@vger.kernel.org/msg17886.html

These topics should all be folded into the videobuf topic. Due to the importance
of videobuf I expect that a considerable amount of time will be spend on this.

On the first day I will probably put this topic last on the list and try to get
through the other topics fairly quickly so that we hopefully have 2-3 hours for
this topic.

What makes this a difficult topic is that you have this list of relatively
small sub-topics (like allocators, out-of-order dequeuing, videobuf improvements,
caching, etc. etc.), but it is not always easy to see the big picture: i.e.
what is the goal that you are working towards and what is the purpose for these
smaller sub-topics in the bigger picture.

I know that was difficult for me in the beginning, so I think it will probably
help people if you also provide the big picture and the context within which to
place these sub-topics. The 'big picture' also includes the memory pool idea.
Not that we will discuss this in Helsinki, but people should be aware that it
will be part of a next phase.

BTW, the videobuf presentation(s) can be longer than 10 minutes if needed.
This is the 'big topic' of the summit, so we will have more time for this.

Regards,

	Hans

> 
> 
> Please let me know what you think. Thanks!
> 
> Best regards
> --
> Pawel Osciak
> Linux Platform Group
> Samsung Poland R&D Center
> 
> 
> 
> 

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco

Re: Tentative agenda for Helsinki mini-summit

[Hans Verkuil]

On Sunday 30 May 2010 09:59:59 Hans Verkuil wrote:
> On Wednesday 26 May 2010 17:46:16 Pawel Osciak wrote:
> > Hi Hans,
> > 
> > thank you for your work on this!
> > 
> > >Hans Verkuil wrote:
> > 
> > >3) videobuf/videobuf2: what are the shortcomings, what are the requirements
> > >for a 'proper' videobuf implementation, can the existing videobuf be fixed or
> > >do we need a videobuf2. If the latter, what would be needed to convert
> > >existing drivers over to a videobuf2. Laurent Pinchart and Pawel Osciak. This I'm
> > >sure requires a presentation.
> > 
> > As Laurent volunteered to prepare the "videobuf problems" presentation, I will
> > hopefully make it before the summit with an initial (general) design for the new
> > videobuf2 - requirements, API, things like that. So I'm thinking about a short
> > presentation on this. What do you think?
> 
> That's OK.
> 
> > >4) Multi-planar support. Pawel Osciak.
> > 
> > Yes. Will provide a short status update. Is a presentation of the whole concept
> > required? If so, I can conduct one as well.
> 
> I don't think a presentation is required.
> 
> > >9) Driver compliance. We need a framework for V4L2 driver compliance. Hans
> > >   Verkuil.
> > 
> > I am very interested in this!
> > 
> > >10) Discuss list of 'reference' programs to test against. Mauro?
> > >
> > 
> > Ditto.
> > 
> > >During the memory handling brainstorming session earlier this year we also
> > >touched on creating some sort of a generic buffer model allowing for easy
> > >exchange between v4l buffers, framebuffers, texture buffers, etc. It is my
> > >opinion that we should not discuss this in Helsinki. The list of topics is
> > >already quite long and I think it is too early to start working on that. We
> > >probably need another brainstorming session first in order to come up with
> > >a reasonable proposal.
> > 
> > I agree.
> > 
> > >Comments? Topics I missed?
> > 
> > It would be great to touch on the following subjects if we find some time
> > (and if people would be interested, I had little feedback on the list):
> > 
> > 1) Custom/pluggable allocators
> > As most of us are aware there are important problems with memory allocation
> > in videobuf that most of us have already faced.
> > For those unfamiliar with the topic, please see my recent RFC:
> > http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/19581
> > 
> > I'd like to provide a design of an API:
> > * for videobuf that would allow drivers to plug-in their own memory allocation
> >   routines,
> > * future-proof enough to be usable with videobuf2 as well.
> > 
> > Hoping for a (short-ish) discussion on that.
> > 
> > 2) Out-of-order buffer dequeuing and per-buffer wait queues in videobuf. See:
> > RFC: http://www.mail-archive.com/linux-media@vger.kernel.org/msg17319.html
> > Patches: http://www.mail-archive.com/linux-media@vger.kernel.org/msg17886.html
> 
> These topics should all be folded into the videobuf topic. Due to the importance
> of videobuf I expect that a considerable amount of time will be spend on this.
> 
> On the first day I will probably put this topic last on the list and try to get
> through the other topics fairly quickly so that we hopefully have 2-3 hours for
> this topic.
> 
> What makes this a difficult topic is that you have this list of relatively
> small sub-topics (like allocators, out-of-order dequeuing, videobuf improvements,
> caching, etc. etc.), but it is not always easy to see the big picture: i.e.
> what is the goal that you are working towards and what is the purpose for these
> smaller sub-topics in the bigger picture.
> 
> I know that was difficult for me in the beginning, so I think it will probably
> help people if you also provide the big picture and the context within which to
> place these sub-topics. The 'big picture' also includes the memory pool idea.
> Not that we will discuss this in Helsinki, but people should be aware that it
> will be part of a next phase.
> 
> BTW, the videobuf presentation(s) can be longer than 10 minutes if needed.
> This is the 'big topic' of the summit, so we will have more time for this.

I just realized this is the second time I replied to your post :-)

Still, my comments at the end of my second reply are hopefully still useful.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco

Re: Tentative agenda for Helsinki mini-summit

[Hans de Goede]

Hi,

I would like to add my "RFC: a processing plugin API for libv4l" to the
schedule, see the mail I just send. This actually is one of the main
reasons for me to come to the summit.

Thanks & Regards,

Hans


On 05/23/2010 12:36 PM, Hans Verkuil wrote:
> Hi all,
>
> This is a tentative agenda for the Helsinki mini-summit on June 14-16.
>
> Please reply to this thread if you have comments or want to add topics.
>
> The overall layout of the summit is to use the first day to go through all
> topics and either come to a conclusion quickly for the 'simple' topics, or
> discuss enough so that everyone understands the problem for the more complex
> issues.
>
> The second day will be used for in-depth discussions on those complex topics
> and on the third day we will go through all topics again and translate the
> discussions into something concrete like a time-line, action items, etc.
>
> We have a lot to discuss, so we may have to split the second day into two
> 'tracks', each discussing different topics. I hope it is not needed, but I
> fear we may have no choice. If we do split up, then one track will touch on
> the videobuf-related topics and the other on the remaining topics.
>
> The first day will also feature a few short presentations on various topics.
> Presentations shouldn't be longer than, say, 10 minutes. These presentations
> are meant to get everyone up to speed quickly.
>
> After each topic I've put the names of the main developers active in that area.
> If you see your name, then make sure you know the status of that topic so you
> can explain it to everyone else. If I think it warrants a presentation, then I
> will mention that. Of course, if you disagree, or want/don't want to do a
> presentation then just say so. It's a tentative agenda only.
>
> The topics below are in no particular order except for the first one. I am
> very pleased that Qualcomm has joined this project so I think it would be
> nice to start the meeting off with a presentation on their HW architecture.
>
> 1) Presentation on the Qualcomm video hw architecture. Most of us have no
>     experience with Qualcomm hardware, so I've asked Jeff Zhong to give a short
>     overview of their video hardware.
>
> 2) Removal of V4L1: status of driver conversion in the kernel, status of
>     moving v4l1->v4l2 conversion into libv4l1. What needs to be done, when
>     will it be done and who will do it. Driver conversion: Hans Verkuil,
>     libv4l1 conversion: Hans de Goede.
>
> 3) videobuf/videobuf2: what are the shortcomings, what are the requirements for
>     a 'proper' videobuf implementation, can the existing videobuf be fixed or do
>     we need a videobuf2. If the latter, what would be needed to convert existing
>     drivers over to a videobuf2. Laurent Pinchart and Pawel Osciak. This I'm sure
>     requires a presentation.
>
> 4) Multi-planar support. Pawel Osciak.
>
> 5) Media Controller Roadmap. Laurent Pinchart. This probably warrants a short
>     presentation.
>
> 6) TO DO list regarding V4L2 core framework including the new control framework.
>     Hans Verkuil. Will be a presentation.
>
> 7) Status of the Texas Instruments drivers: omapX (Hiremath Vaibhav) and DMxxxx
>     (Sergio Aguirre). Probably should be a short presentation.
>
> 8) soc-camera status. Particularly with regards to the remaining soc-camera
>     dependencies in sensor drivers. Guennadi Liakhovetski.
>
> 9) Driver compliance. We need a framework for V4L2 driver compliance. Hans
>     Verkuil.
>
> 10) Discuss list of 'reference' programs to test against. Mauro?
>
> 11) Adopting old V4L1 programs and converting to V4L2. Hans de Goede?
>
> 12) Status of intel drivers. Xiaolin Zhang.
>
> It is my understanding that we will also have X11 and gstreamer experts on hand.
> Topics relating to that are welcome.
>
> During the memory handling brainstorming session earlier this year we also
> touched on creating some sort of a generic buffer model allowing for easy
> exchange between v4l buffers, framebuffers, texture buffers, etc. It is my
> opinion that we should not discuss this in Helsinki. The list of topics is
> already quite long and I think it is too early to start working on that. We
> probably need another brainstorming session first in order to come up with
> a reasonable proposal.
>
> Comments? Topics I missed?
>
> Regards,
>
> 	Hans
>

Re: Tentative agenda for Helsinki mini-summit

[Hans Verkuil]

On Wednesday 26 May 2010 17:47:57 Hans de Goede wrote:
> Hi,
> 
> I would like to add my "RFC: a processing plugin API for libv4l" to the
> schedule, see the mail I just send. This actually is one of the main
> reasons for me to come to the summit.

OK, I'll add it. I'll post an update topic list this weekend.

Regards,

	Hans

> Thanks & Regards,
> 
> Hans
> 
> 
> On 05/23/2010 12:36 PM, Hans Verkuil wrote:
> > Hi all,
> >
> > This is a tentative agenda for the Helsinki mini-summit on June 14-16.
> >
> > Please reply to this thread if you have comments or want to add topics.
> >
> > The overall layout of the summit is to use the first day to go through all
> > topics and either come to a conclusion quickly for the 'simple' topics, or
> > discuss enough so that everyone understands the problem for the more complex
> > issues.
> >
> > The second day will be used for in-depth discussions on those complex topics
> > and on the third day we will go through all topics again and translate the
> > discussions into something concrete like a time-line, action items, etc.
> >
> > We have a lot to discuss, so we may have to split the second day into two
> > 'tracks', each discussing different topics. I hope it is not needed, but I
> > fear we may have no choice. If we do split up, then one track will touch on
> > the videobuf-related topics and the other on the remaining topics.
> >
> > The first day will also feature a few short presentations on various topics.
> > Presentations shouldn't be longer than, say, 10 minutes. These presentations
> > are meant to get everyone up to speed quickly.
> >
> > After each topic I've put the names of the main developers active in that area.
> > If you see your name, then make sure you know the status of that topic so you
> > can explain it to everyone else. If I think it warrants a presentation, then I
> > will mention that. Of course, if you disagree, or want/don't want to do a
> > presentation then just say so. It's a tentative agenda only.
> >
> > The topics below are in no particular order except for the first one. I am
> > very pleased that Qualcomm has joined this project so I think it would be
> > nice to start the meeting off with a presentation on their HW architecture.
> >
> > 1) Presentation on the Qualcomm video hw architecture. Most of us have no
> >     experience with Qualcomm hardware, so I've asked Jeff Zhong to give a short
> >     overview of their video hardware.
> >
> > 2) Removal of V4L1: status of driver conversion in the kernel, status of
> >     moving v4l1->v4l2 conversion into libv4l1. What needs to be done, when
> >     will it be done and who will do it. Driver conversion: Hans Verkuil,
> >     libv4l1 conversion: Hans de Goede.
> >
> > 3) videobuf/videobuf2: what are the shortcomings, what are the requirements for
> >     a 'proper' videobuf implementation, can the existing videobuf be fixed or do
> >     we need a videobuf2. If the latter, what would be needed to convert existing
> >     drivers over to a videobuf2. Laurent Pinchart and Pawel Osciak. This I'm sure
> >     requires a presentation.
> >
> > 4) Multi-planar support. Pawel Osciak.
> >
> > 5) Media Controller Roadmap. Laurent Pinchart. This probably warrants a short
> >     presentation.
> >
> > 6) TO DO list regarding V4L2 core framework including the new control framework.
> >     Hans Verkuil. Will be a presentation.
> >
> > 7) Status of the Texas Instruments drivers: omapX (Hiremath Vaibhav) and DMxxxx
> >     (Sergio Aguirre). Probably should be a short presentation.
> >
> > 8) soc-camera status. Particularly with regards to the remaining soc-camera
> >     dependencies in sensor drivers. Guennadi Liakhovetski.
> >
> > 9) Driver compliance. We need a framework for V4L2 driver compliance. Hans
> >     Verkuil.
> >
> > 10) Discuss list of 'reference' programs to test against. Mauro?
> >
> > 11) Adopting old V4L1 programs and converting to V4L2. Hans de Goede?
> >
> > 12) Status of intel drivers. Xiaolin Zhang.
> >
> > It is my understanding that we will also have X11 and gstreamer experts on hand.
> > Topics relating to that are welcome.
> >
> > During the memory handling brainstorming session earlier this year we also
> > touched on creating some sort of a generic buffer model allowing for easy
> > exchange between v4l buffers, framebuffers, texture buffers, etc. It is my
> > opinion that we should not discuss this in Helsinki. The list of topics is
> > already quite long and I think it is too early to start working on that. We
> > probably need another brainstorming session first in order to come up with
> > a reasonable proposal.
> >
> > Comments? Topics I missed?
> >
> > Regards,
> >
> > 	Hans
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco