Re: V4L2 and framebuffer for the same controller

Re: V4L2 and framebuffer for the same controller

[Guennadi Liakhovetski]

Hi Jun

On Fri, 29 Oct 2010, Jun Nie wrote:

> Hi Guennadi,
>     I find that your idea of "provide a generic framebuffer driver
> that could sit on top of a v4l output driver", which may be a good
> solution of our LCD controller driver, or maybe much more other SOC
> LCD drivers. V4L2 interface support many features than framebuffer for
> video playback usage, such as buffer queue/dequeue, quality control,
> etc. However, framebuffer is common for UI display. Implement two
> drivers for one controller is a challenge for current architecture.
>     I am interested in your idea. Could you elaborate it? Or do you
> think multifunction driver is the right solution for this the
> scenario?

Right, we have discussed this idea at the V4L2/MC mini-summit earlier this 
year, there the outcome was, that the idea is not bad, but it is easy 
enough to create such framebuffer additions on top of specific v4l2 output 
drivers anyway, so, noone was interested enough to start designing and 
implementing such a generic wrapper driver. However, I've heard, that this 
topic has also been scheduled for discussion at another v4l / kernel 
meeting (plumbers?), so, someone might be looking into implementing 
this... If you yourself would like to do that - feel free to propose a 
design on both mailing lists (fbdev added to cc), then we can discuss it, 
and you can implement it;)

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

Re: V4L2 and framebuffer for the same controller

[Jun Nie]

2010/11/2 Guennadi Liakhovetski <g.liakhovetski@gmx.de>:
> Hi Jun
>
> On Fri, 29 Oct 2010, Jun Nie wrote:
>
>> Hi Guennadi,
>>     I find that your idea of "provide a generic framebuffer driver
>> that could sit on top of a v4l output driver", which may be a good
>> solution of our LCD controller driver, or maybe much more other SOC
>> LCD drivers. V4L2 interface support many features than framebuffer for
>> video playback usage, such as buffer queue/dequeue, quality control,
>> etc. However, framebuffer is common for UI display. Implement two
>> drivers for one controller is a challenge for current architecture.
>>     I am interested in your idea. Could you elaborate it? Or do you
>> think multifunction driver is the right solution for this the
>> scenario?
>
> Right, we have discussed this idea at the V4L2/MC mini-summit earlier this
> year, there the outcome was, that the idea is not bad, but it is easy
> enough to create such framebuffer additions on top of specific v4l2 output
> drivers anyway, so, noone was interested enough to start designing and
> implementing such a generic wrapper driver. However, I've heard, that this
> topic has also been scheduled for discussion at another v4l / kernel
> meeting (plumbers?), so, someone might be looking into implementing
> this... If you yourself would like to do that - feel free to propose a
> design on both mailing lists (fbdev added to cc), then we can discuss it,
> and you can implement it;)
>
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
>

Good to know others are also interested in it. I surely can contribute
to it. But my concern is how to support Xwindow. Android and Ubuntu
should both run on our platform. Queue/deque should work well for
Android UI. I still can not figure out how to support Xwindow, for it
does not interact with driver after it get the mmaped buffer.

Jun

Re: V4L2 and framebuffer for the same controller

[Jun Nie]

2010/11/8 Jun Nie <niej0001@gmail.com>:
> 2010/11/2 Guennadi Liakhovetski <g.liakhovetski@gmx.de>:
>> Hi Jun
>>
>> On Fri, 29 Oct 2010, Jun Nie wrote:
>>
>>> Hi Guennadi,
>>>     I find that your idea of "provide a generic framebuffer driver
>>> that could sit on top of a v4l output driver", which may be a good
>>> solution of our LCD controller driver, or maybe much more other SOC
>>> LCD drivers. V4L2 interface support many features than framebuffer for
>>> video playback usage, such as buffer queue/dequeue, quality control,
>>> etc. However, framebuffer is common for UI display. Implement two
>>> drivers for one controller is a challenge for current architecture.
>>>     I am interested in your idea. Could you elaborate it? Or do you
>>> think multifunction driver is the right solution for this the
>>> scenario?
>>
>> Right, we have discussed this idea at the V4L2/MC mini-summit earlier this
>> year, there the outcome was, that the idea is not bad, but it is easy
>> enough to create such framebuffer additions on top of specific v4l2 output
>> drivers anyway, so, noone was interested enough to start designing and
>> implementing such a generic wrapper driver. However, I've heard, that this
>> topic has also been scheduled for discussion at another v4l / kernel
>> meeting (plumbers?), so, someone might be looking into implementing
>> this... If you yourself would like to do that - feel free to propose a
>> design on both mailing lists (fbdev added to cc), then we can discuss it,
>> and you can implement it;)
>>
>> Thanks
>> Guennadi
>> ---
>> Guennadi Liakhovetski, Ph.D.
>> Freelance Open-Source Software Developer
>> http://www.open-technology.de/
>>
>
> Good to know others are also interested in it. I surely can contribute
> to it. But my concern is how to support Xwindow. Android and Ubuntu
> should both run on our platform. Queue/deque should work well for
> Android UI. I still can not figure out how to support Xwindow, for it
> does not interact with driver after it get the mmaped buffer.
>
> Jun
>

Guennadi,

Any idea on supporting this feature with V4L2 based FB? I can not
figure out any method and will adopt framebuffer for UI and V4L2 for
video layer for the schedule pressure.

Jun

Re: V4L2 and framebuffer for the same controller

[Guennadi Liakhovetski]

On Mon, 15 Nov 2010, Jun Nie wrote:

> 2010/11/8 Jun Nie <niej0001@gmail.com>:
> > 2010/11/2 Guennadi Liakhovetski <g.liakhovetski@gmx.de>:
> >> Hi Jun
> >>
> >> On Fri, 29 Oct 2010, Jun Nie wrote:
> >>
> >>> Hi Guennadi,
> >>>     I find that your idea of "provide a generic framebuffer driver
> >>> that could sit on top of a v4l output driver", which may be a good
> >>> solution of our LCD controller driver, or maybe much more other SOC
> >>> LCD drivers. V4L2 interface support many features than framebuffer for
> >>> video playback usage, such as buffer queue/dequeue, quality control,
> >>> etc. However, framebuffer is common for UI display. Implement two
> >>> drivers for one controller is a challenge for current architecture.
> >>>     I am interested in your idea. Could you elaborate it? Or do you
> >>> think multifunction driver is the right solution for this the
> >>> scenario?
> >>
> >> Right, we have discussed this idea at the V4L2/MC mini-summit earlier this
> >> year, there the outcome was, that the idea is not bad, but it is easy
> >> enough to create such framebuffer additions on top of specific v4l2 output
> >> drivers anyway, so, noone was interested enough to start designing and
> >> implementing such a generic wrapper driver. However, I've heard, that this
> >> topic has also been scheduled for discussion at another v4l / kernel
> >> meeting (plumbers?), so, someone might be looking into implementing
> >> this... If you yourself would like to do that - feel free to propose a
> >> design on both mailing lists (fbdev added to cc), then we can discuss it,
> >> and you can implement it;)
> >>
> >> Thanks
> >> Guennadi
> >> ---
> >> Guennadi Liakhovetski, Ph.D.
> >> Freelance Open-Source Software Developer
> >> http://www.open-technology.de/
> >>
> >
> > Good to know others are also interested in it. I surely can contribute
> > to it. But my concern is how to support Xwindow. Android and Ubuntu
> > should both run on our platform. Queue/deque should work well for
> > Android UI. I still can not figure out how to support Xwindow, for it
> > does not interact with driver after it get the mmaped buffer.
> >
> > Jun
> >
> 
> Guennadi,
> 
> Any idea on supporting this feature with V4L2 based FB? I can not
> figure out any method and will adopt framebuffer for UI and V4L2 for
> video layer for the schedule pressure.

Hi Jun

Sorry, not sure I understand you right here. You are saying, that atm you 
don't have the time to work on a generic solution and are going for a 
specific one, right? Yes, that's what everybody is currently doing. And 
you're asking whether I am working or am going to work on such a generic 
solution? No, sorry, I don't think I'll have time for it either in the 
near future.

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

Re: V4L2 and framebuffer for the same controller

[Jun Nie]

2010/11/15 Guennadi Liakhovetski <g.liakhovetski@gmx.de>:
> On Mon, 15 Nov 2010, Jun Nie wrote:
>
>> 2010/11/8 Jun Nie <niej0001@gmail.com>:
>> > 2010/11/2 Guennadi Liakhovetski <g.liakhovetski@gmx.de>:
>> >> Hi Jun
>> >>
>> >> On Fri, 29 Oct 2010, Jun Nie wrote:
>> >>
>> >>> Hi Guennadi,
>> >>>     I find that your idea of "provide a generic framebuffer driver
>> >>> that could sit on top of a v4l output driver", which may be a good
>> >>> solution of our LCD controller driver, or maybe much more other SOC
>> >>> LCD drivers. V4L2 interface support many features than framebuffer for
>> >>> video playback usage, such as buffer queue/dequeue, quality control,
>> >>> etc. However, framebuffer is common for UI display. Implement two
>> >>> drivers for one controller is a challenge for current architecture.
>> >>>     I am interested in your idea. Could you elaborate it? Or do you
>> >>> think multifunction driver is the right solution for this the
>> >>> scenario?
>> >>
>> >> Right, we have discussed this idea at the V4L2/MC mini-summit earlier this
>> >> year, there the outcome was, that the idea is not bad, but it is easy
>> >> enough to create such framebuffer additions on top of specific v4l2 output
>> >> drivers anyway, so, noone was interested enough to start designing and
>> >> implementing such a generic wrapper driver. However, I've heard, that this
>> >> topic has also been scheduled for discussion at another v4l / kernel
>> >> meeting (plumbers?), so, someone might be looking into implementing
>> >> this... If you yourself would like to do that - feel free to propose a
>> >> design on both mailing lists (fbdev added to cc), then we can discuss it,
>> >> and you can implement it;)
>> >>
>> >> Thanks
>> >> Guennadi
>> >> ---
>> >> Guennadi Liakhovetski, Ph.D.
>> >> Freelance Open-Source Software Developer
>> >> http://www.open-technology.de/
>> >>
>> >
>> > Good to know others are also interested in it. I surely can contribute
>> > to it. But my concern is how to support Xwindow. Android and Ubuntu
>> > should both run on our platform. Queue/deque should work well for
>> > Android UI. I still can not figure out how to support Xwindow, for it
>> > does not interact with driver after it get the mmaped buffer.
>> >
>> > Jun
>> >
>>
>> Guennadi,
>>
>> Any idea on supporting this feature with V4L2 based FB? I can not
>> figure out any method and will adopt framebuffer for UI and V4L2 for
>> video layer for the schedule pressure.
>
> Hi Jun
>
> Sorry, not sure I understand you right here. You are saying, that atm you
> don't have the time to work on a generic solution and are going for a
> specific one, right? Yes, that's what everybody is currently doing. And
> you're asking whether I am working or am going to work on such a generic
> solution? No, sorry, I don't think I'll have time for it either in the
> near future.
>
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
>


Hi Guennadi
   I mean I have no idea on how to support Xwindow's requirement if FB
is based on V4L2. I can contribute on V4L2 based FB if it is clear.
But I will do as everbody does currently.

Jun

Re: V4L2 and framebuffer for the same controller

[Guennadi Liakhovetski]

On Mon, 15 Nov 2010, Jun Nie wrote:

> 2010/11/15 Guennadi Liakhovetski <g.liakhovetski@gmx.de>:
> > On Mon, 15 Nov 2010, Jun Nie wrote:
> >
> >> 2010/11/8 Jun Nie <niej0001@gmail.com>:
> >> > 2010/11/2 Guennadi Liakhovetski <g.liakhovetski@gmx.de>:
> >> >> Hi Jun
> >> >>
> >> >> On Fri, 29 Oct 2010, Jun Nie wrote:
> >> >>
> >> >>> Hi Guennadi,
> >> >>>     I find that your idea of "provide a generic framebuffer driver
> >> >>> that could sit on top of a v4l output driver", which may be a good
> >> >>> solution of our LCD controller driver, or maybe much more other SOC
> >> >>> LCD drivers. V4L2 interface support many features than framebuffer for
> >> >>> video playback usage, such as buffer queue/dequeue, quality control,
> >> >>> etc. However, framebuffer is common for UI display. Implement two
> >> >>> drivers for one controller is a challenge for current architecture.
> >> >>>     I am interested in your idea. Could you elaborate it? Or do you
> >> >>> think multifunction driver is the right solution for this the
> >> >>> scenario?
> >> >>
> >> >> Right, we have discussed this idea at the V4L2/MC mini-summit earlier this
> >> >> year, there the outcome was, that the idea is not bad, but it is easy
> >> >> enough to create such framebuffer additions on top of specific v4l2 output
> >> >> drivers anyway, so, noone was interested enough to start designing and
> >> >> implementing such a generic wrapper driver. However, I've heard, that this
> >> >> topic has also been scheduled for discussion at another v4l / kernel
> >> >> meeting (plumbers?), so, someone might be looking into implementing
> >> >> this... If you yourself would like to do that - feel free to propose a
> >> >> design on both mailing lists (fbdev added to cc), then we can discuss it,
> >> >> and you can implement it;)
> >> >>
> >> >> Thanks
> >> >> Guennadi
> >> >> ---
> >> >> Guennadi Liakhovetski, Ph.D.
> >> >> Freelance Open-Source Software Developer
> >> >> http://www.open-technology.de/
> >> >>
> >> >
> >> > Good to know others are also interested in it. I surely can contribute
> >> > to it. But my concern is how to support Xwindow. Android and Ubuntu
> >> > should both run on our platform. Queue/deque should work well for
> >> > Android UI. I still can not figure out how to support Xwindow, for it
> >> > does not interact with driver after it get the mmaped buffer.
> >> >
> >> > Jun
> >> >
> >>
> >> Guennadi,
> >>
> >> Any idea on supporting this feature with V4L2 based FB? I can not
> >> figure out any method and will adopt framebuffer for UI and V4L2 for
> >> video layer for the schedule pressure.
> >
> > Hi Jun
> >
> > Sorry, not sure I understand you right here. You are saying, that atm you
> > don't have the time to work on a generic solution and are going for a
> > specific one, right? Yes, that's what everybody is currently doing. And
> > you're asking whether I am working or am going to work on such a generic
> > solution? No, sorry, I don't think I'll have time for it either in the
> > near future.
> >
> > Thanks
> > Guennadi
> > ---
> > Guennadi Liakhovetski, Ph.D.
> > Freelance Open-Source Software Developer
> > http://www.open-technology.de/
> >
> 
> 
> Hi Guennadi
>    I mean I have no idea on how to support Xwindow's requirement if FB
> is based on V4L2. I can contribute on V4L2 based FB if it is clear.
> But I will do as everbody does currently.

Maybe you didn't understand the concept of this driver then. The shole 
idea is to have a v4l2 output driver as a base and add a framebuffer 
translation layer on the top. Which would provide two interfaces to the 
user: a v4l2 one with frame queuing etc, and a standard fb one, which 
should be usable by any fb application (X, directfb,...) natively.

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

Re: V4L2 and framebuffer for the same controller

[Jun Nie]

2010/11/15 Guennadi Liakhovetski <g.liakhovetski@gmx.de>:
> On Mon, 15 Nov 2010, Jun Nie wrote:
>
>> 2010/11/15 Guennadi Liakhovetski <g.liakhovetski@gmx.de>:
>> > On Mon, 15 Nov 2010, Jun Nie wrote:
>> >
>> >> 2010/11/8 Jun Nie <niej0001@gmail.com>:
>> >> > 2010/11/2 Guennadi Liakhovetski <g.liakhovetski@gmx.de>:
>> >> >> Hi Jun
>> >> >>
>> >> >> On Fri, 29 Oct 2010, Jun Nie wrote:
>> >> >>
>> >> >>> Hi Guennadi,
>> >> >>>     I find that your idea of "provide a generic framebuffer driver
>> >> >>> that could sit on top of a v4l output driver", which may be a good
>> >> >>> solution of our LCD controller driver, or maybe much more other SOC
>> >> >>> LCD drivers. V4L2 interface support many features than framebuffer for
>> >> >>> video playback usage, such as buffer queue/dequeue, quality control,
>> >> >>> etc. However, framebuffer is common for UI display. Implement two
>> >> >>> drivers for one controller is a challenge for current architecture.
>> >> >>>     I am interested in your idea. Could you elaborate it? Or do you
>> >> >>> think multifunction driver is the right solution for this the
>> >> >>> scenario?
>> >> >>
>> >> >> Right, we have discussed this idea at the V4L2/MC mini-summit earlier this
>> >> >> year, there the outcome was, that the idea is not bad, but it is easy
>> >> >> enough to create such framebuffer additions on top of specific v4l2 output
>> >> >> drivers anyway, so, noone was interested enough to start designing and
>> >> >> implementing such a generic wrapper driver. However, I've heard, that this
>> >> >> topic has also been scheduled for discussion at another v4l / kernel
>> >> >> meeting (plumbers?), so, someone might be looking into implementing
>> >> >> this... If you yourself would like to do that - feel free to propose a
>> >> >> design on both mailing lists (fbdev added to cc), then we can discuss it,
>> >> >> and you can implement it;)
>> >> >>
>> >> >> Thanks
>> >> >> Guennadi
>> >> >> ---
>> >> >> Guennadi Liakhovetski, Ph.D.
>> >> >> Freelance Open-Source Software Developer
>> >> >> http://www.open-technology.de/
>> >> >>
>> >> >
>> >> > Good to know others are also interested in it. I surely can contribute
>> >> > to it. But my concern is how to support Xwindow. Android and Ubuntu
>> >> > should both run on our platform. Queue/deque should work well for
>> >> > Android UI. I still can not figure out how to support Xwindow, for it
>> >> > does not interact with driver after it get the mmaped buffer.
>> >> >
>> >> > Jun
>> >> >
>> >>
>> >> Guennadi,
>> >>
>> >> Any idea on supporting this feature with V4L2 based FB? I can not
>> >> figure out any method and will adopt framebuffer for UI and V4L2 for
>> >> video layer for the schedule pressure.
>> >
>> > Hi Jun
>> >
>> > Sorry, not sure I understand you right here. You are saying, that atm you
>> > don't have the time to work on a generic solution and are going for a
>> > specific one, right? Yes, that's what everybody is currently doing. And
>> > you're asking whether I am working or am going to work on such a generic
>> > solution? No, sorry, I don't think I'll have time for it either in the
>> > near future.
>> >
>> > Thanks
>> > Guennadi
>> > ---
>> > Guennadi Liakhovetski, Ph.D.
>> > Freelance Open-Source Software Developer
>> > http://www.open-technology.de/
>> >
>>
>>
>> Hi Guennadi
>>    I mean I have no idea on how to support Xwindow's requirement if FB
>> is based on V4L2. I can contribute on V4L2 based FB if it is clear.
>> But I will do as everbody does currently.
>
> Maybe you didn't understand the concept of this driver then. The shole
> idea is to have a v4l2 output driver as a base and add a framebuffer
> translation layer on the top. Which would provide two interfaces to the
> user: a v4l2 one with frame queuing etc, and a standard fb one, which
> should be usable by any fb application (X, directfb,...) natively.
>
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
>

You mean fb with V4L2 interface will manage memory with video-buf and
standard fb interface still handle memory independently, ie. get
memory with dma_alloc_writecombine directly?

Thanks!
Jun