On Tuesday, February 08, 2011 16:28:32 Alex Deucher wrote: > On Tue, Feb 8, 2011 at 4:47 AM, Hans Verkuil <hansverk@xxxxxxxxx> wrote: <snip> > >> The driver supports an interrupt. It is used to detect plug/unplug events > > in > >> kernel debugs. The API for detection of such an events in V4L2 API is to be > >> defined. > > > > Cisco (i.e. a few colleagues and myself) are working on this. We hope to post > > an RFC by the end of this month. We also have a proposal for CEC support in > > the pipeline. > > Any reason to not use the drm kms APIs for modesetting, display > configuration, and hotplug support? We already have the > infrastructure in place for complex display configurations and > generating events for hotplug interrupts. It would seem to make more > sense to me to fix any deficiencies in the KMS APIs than to spin a new > API. Things like CEC would be a natural fit since a lot of desktop > GPUs support hdmi audio/3d/etc. and are already using kms. There are various reasons for not going down that road. The most important one is that mixing APIs is actually a bad idea. I've done that once in the past and I've regretted ever since. The problem with doing that is that it is pretty hard on applications who have to mix two different styles of API, somehow know where to find the documentation for each and know that both APIs can in fact be used on the same device. Now, if there was a lot of code that could be shared, then that might be enough reason to go that way, but in practice there is very little overlap. Take CEC: all the V4L API will do is to pass the CEC packets from kernel to userspace and vice versa. There is no parsing at all. This is typically used by embedded apps that want to do their own CEC processing. An exception might be a PCI(e) card with HDMI input/output that wants to handle CEC internally. At that point we might look at sharing CEC parsing code. A similar story is true for EDID handling. One area that might be nice to look at would be to share drivers for HDMI receivers and transmitters. However, the infrastructure for such drivers is wildly different between how it is used for GPUs versus V4L and has been for 10 years or so. I also suspect that most GPUs have there own HDMI internal implementation so code sharing will probably be quite limited. So, no, there are no plans to share anything between the two (except perhaps EDID and CEC parsing should that become relevant). Oh, and let me join Andy in saying that the drm/kms/whatever API documentation *really* needs a lot of work. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |