Hi,
On Mon, 10 Nov 2008, ext Shah, Hardik wrote:
[Shah, Hardik] We have reviewed the patches in detail and even made modifications to make it work on the OMAP3EVM. Here are our observations:
1) The overall implementation is very much in line with our earlier proposal to provide generic API that supports both V4L2 and FBDEV.
2) The implementation supports multiple output interfaces e.g. RFBI, SDI, DSI, ... that we did not have in our plans
3) You have also validated it on lot many platforms that we do not have access.
We believe patches are a good step in right direction.
We plan to use this patchset as base for supporting these additional use cases:
a) Adding the V4L2 user interface to the video pipelines (I believe video pipelines are natural fit for the V4L2 frame work. If use case is there for FBDEV interface we can have compile time option to expose the video pipelines as the either FBDEV or v4L2 interface).
b) Modification of the DSS/DISPC library for supporting V4L2 user interface.
c) Supporting the functionality like alpha blending, global alpha blending, setting of various TV standards etc.
d) Supporting the mirroring and rotation in both FBDEV and V4L2 driver.
Do let us know if you aren't already working on any of these.
This sounds very good. I am not currently working on any of those items
you mentioned. A couple of comments/thoughts about them:
a) Yes, V4L2 interface would be nice. But there are use cases for FB
devices also, and sometimes you don't want V4L2 devices at all. So as you
suggested, a compile time option to select this is necessary. Or, better
yet, a runtime option.
One way to implement simultaneous FB and V4L2 devices is to have to
separate drivers. But then this needs more locking support to DSS, and
pobably some kind of event mechanism. For example, if both FB and V4L2
have overlays on the same display, and one of them changes the screen
resolution, the other one needs to know about this also.
So what I have been thinking is to have both FB and V4L2 in the same
driver. This would make things easier. But then again, I don't know how
much code V4L2 needs, and if the combined driver would get too complex.
b) Do you already have ideas what features V4L2 needs that are not present
in DSS currently?
c) Yes, these would be nice.
d) These would be nice also. About rotation, I think there are three kinds
of rotation that are handled by different entities:
- DMA rotation, for framebuffers in SRAM. Handled by DSS.
- External framebuffer rotation, handled by the external framebuffer
controller.
- VRFB rotation. This is basically a memory handling configuration, and is
transparent to the end user (in this case, DSS) of the memory. Should be
handled by the entity that allocates the memory, ie. omapfb.
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
