On Thu, May 27, 2010 at 2:56 PM, Guennadi Liakhovetski <g.liakhovetski@xxxxxx> wrote: > (adding V4L ML to CC and preserving the complete reply for V4L readers) > > On Thu, 27 May 2010, Jaya Kumar wrote: > >> On Wed, May 26, 2010 at 10:09 PM, Guennadi Liakhovetski >> <g.liakhovetski@xxxxxx> wrote: > Ok, let me explain what exactly I meant. Above I referred to "display > drivers," which is not the same as a "framebuffer controller driver" or > whatever you would call it. By framebuffer controller driver I mean a > driver for the actual graphics engine on a certain graphics card or an > SoC. This is the part, that reads data from the actual framebuffer and > outputs it to some hardware interface to a display device. Now this > interface can be a VGA or a DVI connector, it can be one of several bus > types, used with various LCD displays. In many cases this is all you have > to do to get the output to your display. But in some cases the actual > display on the other side of this bus also requires a driver. That can be > some kind of a smart display, it can be a panel with an attached display > controller, that must be at least configured, say, over SPI, it can be a > display, attached to the host over the MIPI DSI bus, and implementing some > proprietary commands. In each of these cases you will have to write a > display driver for this specific display or controller type, and your > framebuffer driver will have to interface with that display driver. Now, > obviously, those displays can be connected to a variety of host systems, > in which case you will want to reuse that display driver. This means, > there has to be a standard fb-driver - display-driver API. AFAICS, this is > currently not implemented in fbdev, please, correct me if I am wrong. Thanks Guennadi, your clarification is useful. Yes, you are correct. There is no general fbdev API provided so that a host controller driver and a independent display panel driver can interface in a clean abstracted way. You've raised the MIPI-DSI issue. It is a good area to focus the discussion on for fbdev minded people and one that needs to be resolved soon so that we don't get dozens of host controller specific mipi display panel drivers. I had seen that omap2 fbdev has a portion of the MIPI-DSI command set exposed to their various display panel drivers which then hands off these commands to the omap specific lcd_mipid.c which uses spi. I see you've also implemented a similar concept in sh-mobile. When I saw the multiple display panel drivers showing up in omap, I raised a concern with Tomi and I think there was an intent to try to improve the abstraction. I'm not sure how far that has progressed. Are you saying v4l would help us in that area? I'm not yet able to follow the details of how using v4l would help address the need for mipi-dsi abstraction. Could you elaborate on that? Thanks, jaya -- 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
