2010/11/15 Guennadi Liakhovetski <g.liakhovetski@xxxxxx>: > On Mon, 15 Nov 2010, Jun Nie wrote: > >> 2010/11/15 Guennadi Liakhovetski <g.liakhovetski@xxxxxx>: >> > On Mon, 15 Nov 2010, Jun Nie wrote: >> > >> >> 2010/11/8 Jun Nie <niej0001@xxxxxxxxx>: >> >> > 2010/11/2 Guennadi Liakhovetski <g.liakhovetski@xxxxxx>: >> >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
