Tomi, Have you got a chance to review the DSS library and V4l2 driver which we have posted? Thanks, Vaibhav Hiremath Senior Software Engg. Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 > -----Original Message----- > From: Hiremath, Vaibhav > Sent: Monday, September 15, 2008 9:51 PM > To: 'Tomi Valkeinen' > Cc: Shah, Hardik; linux-omap@xxxxxxxxxxxxxxx; video4linux-list@xxxxxxxxxx > Subject: RE: [PREVIEW] New display subsystem for OMAP2/3 > > > > 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
