Koen Kooi <k.kooi@xxxxxxxxxxxxxxxxxx> writes: > Op 12 sep 2008, om 17:29 heeft Daniel Stone het volgende geschreven: > >> On Fri, Sep 12, 2008 at 07:59:44PM +0530, ext Shah, Hardik wrote: >>> It's time to re-design DSS frame buffer driver for the OMAP2/3. >>> Current frame buffer driver is not covering the most of the >>> functionality of the OMAP2/3 DSS Hardware like multiple outputs and >>> multiple overlay managers supported by OMAP2/3 class of SoC. Again >>> there is no V4L2 interface exposed by the DSS drivers for >>> controlling the video pipelines of the DSS which is highly >>> desirable feature as the video pipelines of the DSS hardware is a >>> natural fit to the V4L2 architecture. >> >> If you want to use v4l for video output, don't let me stop you, but I >> don't see that it has much actual wide use beyond TI PowerPoint >> presentations about their graphical architecture. > > That was my thought as well, but I've encountered at least 2 products > this weekend at IBC using the v4l way on omap3. One of the engineers > was complaining about the lack of synchronous updates if you move > various videoplanes around (think resizing video windows) which makes > the video picture end up outside your nice cairo-drawn borders. So > yes, it is getting used outside of TI :) I'm thinking the best solution is probably to have a low-level internal driver providing access to various planes, exposing as much functionality as is practical. Various user-space interfaces, such as fbdev and v4l, could then be implemented on top of this with very little code. If I've understood things correctly, this is essentially what the patch in this thread is doing. This approach should let the TI people and Koen's mythical friends from IBC use the v4l2 interface, while still allowing the less masochistic among us to use a simpler interface. What I don't like about the patch posted is its size. I'm sure the transition could be done in a sequence of smaller patches. At the very least, it should be possible to move existing functionality to the new architecture, then add the new parts afterwards. I also see little value in keeping the old model around, as is done in the patch. -- Måns Rullgård mans@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
