On Fri, 2008-09-12 at 19:59 +0530, ext Shah, Hardik wrote: > > > -----Original Message----- > > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of Tomi > > Valkeinen > > Sent: Thursday, September 11, 2008 8:26 PM > > To: linux-omap@xxxxxxxxxxxxxxx > > Subject: [PREVIEW] New display subsystem for OMAP2/3 > > > > Display Subsystem driver for OMAP2 and 3 (DSS2) > > ----------------------------------------------- > Hi, > 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. > > We have already initiated the re-designing of the DSS drivers and already posted the RFC for the same on the Linux-Omap and the V4L2 mailing lists. Below is the link for the RFC submitted by us on the open source mailing lists - > > http://lists-archives.org/video4linux/23648-omap3-display-driver-v4l2.html > http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg02510.html Ah, I seem to have missed these, I was on my summer holidays at that time =). I'll study those. > > Typically most of the modern display devices which include the OMAP2 and OMAP3, are required to support two separate types of interfaces - V4L2 interface for the video planes and fbdev interface for graphics planes. It is impossible for these two drivers on separate frameworks to co-exist as independent full fledged drivers. Hence this has been one of the main aspects we are trying to address through our design, which includes as a common DSS library which can be used by both of the drivers. > > VIDEO0(V4L2) VIDEO1(V4L2) GFX0(fbdev0) > | | | > | | | > ----DSS Library---- > | | > LCD TV > > > Here, the DSS library is the central set of APIs which is designed to make sure that, there are no conflicts for resources, resources being the Graphics plane (pipeline), Video planes (pipelines) and Overlay Managers. Display library is not tied to any interfaces, like V4L2 or FBDEV. > > Output devices registers to the DSS library and applications will be able to switch/exchange/change parameters through their interfaces going through the DSS library. > > We believe that currently your implementation does not address these important aspects and lot of the users will be at loss of functionality if this is not addressed. I haven't used much time on the userspace interface, so my fb driver is just a copy of the old omapfb. It sounds my implementation is somewhat similar to yours. The DSS driver is not tied to fb or v4l interface, and offers ways to configure the displays and planes however you want. I concentrated more on the the lower part than to fbdev or v4l, and more specifically I needed DSI support and multiple display support, while still retaining the old functionality. And with multiple displays I don't mean just an LCD and a TV-out, but, for example, two LCD's and tv-out. Configurations like one LCD connected to parallel output, updated with DISPC, and the other one connected to DSI and updated with CPU or system DMA. Or two displays connected to DSI. I also wanted to be able to change the configuration on the fly, changing where DISPC output is going and which displays are updated with CPU or sDMA. This is why I have the display-concept in my design. I haven't made support for multiple users of the displays (like separate fb and v4l drivers), but I don't immediately see why it couldn't be done. However, there are some questions regarding that, as the planes do not represent displays, but just overlay planes. What happens when both fb and v4l drivers want to change the resolution or timings of the display? Also I still don't quite know how to present displays to user space. Currently my omapfb just uses the first display, and that's it. I think in the end the user (be it X server, or perhaps some entity over it), needs to have some understanding of what OMAP offers and how it can use the displays. And there probably needs to be some product spesific configuration regarding this in userspace. > Thanks and Regards, > Hardik Tomi -- 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
