Thanks, Vaibhav Hiremath Senior Software Engg. Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 TI IP Ph: 509-9927 http://dbdwss01.india.ti.com/pspproducts/ > -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of Tomi > Valkeinen > Sent: Monday, September 15, 2008 8:08 PM > To: Hiremath, Vaibhav > Cc: Shah, Hardik; linux-omap@xxxxxxxxxxxxxxx; video4linux-list@xxxxxxxxxx > Subject: RE: [PREVIEW] New display subsystem for OMAP2/3 > > On Mon, 2008-09-15 at 19:02 +0530, ext Hiremath, Vaibhav wrote: > > > We more concentrated on TV and LCD interface, out design doesn't support DSI as of now. As > mentioned earlier it is easily extendible to support DSI. > > > > If I understand your implementation correctly, right now there is no way you can switch the > outputs, I mean to say from LCD to DVI. The frame buffer driver gets the handle with API > omap_dss_get_display, which will return pointer to omap_display for panel-sdp3430. Henceforth all > your functions will use omap_display configuring for LCD panel. How are you planning to add support > for this? Through some ioctls or sysfs entry? How about switching between multiple overlay managers? > > You can switch the outputs in the DSS driver. You can enable/disable > displays individually, and configure the planes and or L4 pixel source > for the display. > > But yes, the fb driver does not support that currently. > > One idea I had was to present each display with one framebuffer, so > let's say we have 3 displays, we would have fb[0-2]. In addition to > that, we would have two framebuffers for the video overlays. Only one of > the displays can be updated with DISPC, so the overlays would appear > there. > > Then the display that is updated with DISPC could be changed on the fly > to another one, but the framebuffer arrangement would stay the same (so > fb0 would still be seen on display0, even if it's now updated with L4). > > There's still the question how to manage the video overlays, in this > scenario they would automatically move to other LCD's as the DISPC > target is changed. Also the TV-out is problematic. > > > This issue has been addresses with our design, you can change the output either to TV, LCD or to > DVI through sysfs entry. Switching between multiple overlay managers is very well supported in DSS > library. Currently SYSFS is the user interface layer to control the overlay managers. But in future > DSS library will easily be suitable to support media processor interface which is in concept phase > right now. RFC for the media processor is at > > Does your design support displays that are not updated with DISPC? Yes, it should. I don't see any reason why it should fail if the display is completely independent. > > Your design has good points. I have to think about the overlay managers > a bit more. Especially if in some future hardware there were more > overlay managers instead of the current two. > Let me take this opportunity, shortly I will post the DSS library and V4L2 driver. We can work together to add support for DSI, RFBI and SDI support to it. > > http://lists-archives.org/video4linux/23652-rfc-add-support-to-query-and-change-connections-inside- > a-media-device.html > > > > > > > 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. > > > > > > > > > Here we both are on same page, you have broken the displays and modes supported into multiple files > registering functions to the display.c file, there are many loopholes though. > > > > > 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. > > > > > > > How are you going to handle the concurrency between these two? > > In the simple case of just an LCD and a TV-out, what are the concurrency > problems? Each plane is independent of each other. Sure you need to > check that the output is on if there's a plane enabled there and basic > things like that. Are there some other issues I'm not seeing? > Yes some of the features of the DSS are tied to overlay managers and not the individual planes like global alpha, alpha blending enabling and timing parameters. So while programming of these parameters DSS library will have to maintain the data structures for the same and then any high level drivers can query those data structures. > > > 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. > > > > > > > Here are you saying application will have hardware specific support? Is this feasible? > > > > I don't see any other way. The displays are not independent of each > other. For example the OMAP3 SDP has LCD and DVI outputs. They can't be > switched programmatically, but let's say it was possible. Only one of > those displays can be enabled at time. If an application wants to use > them both, it has to understand that they will not both work at the same > time. > > Or if there are two DSI displays, and one is updated with DISPC and the > other via L4. The application has to know that a video overlay can only > be used on the first display, or it has to exchange the DISPC/L4 > updating order. > > Of course this is product specific software and configuration, not > something I'm planning to put in the driver. A normal application does > not have to know anything about it. I was just bringing it up to > demonstrate what must be possible. > > 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 -- 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
