On 2/16/12 6:25 PM, Laurent Pinchart wrote: > *** Common video mode data structure and EDID parser *** > > Goal: Sharing an EDID parser between DRM/KMS, FBDEV and V4L2. > > The DRM EDID parser is currently the most advanced implementation and will > be taken as a starting point. > > Different subsystems use different data structures to describe video > mode/timing information: > > - struct drm_mode_modeinfo in DRM/KMS > - struct fb_videomode in FBDEV > - struct v4l2_bt_timings in V4L2 > > A new common video mode/timing data structure (struct > media_video_mode_info, > exact name is to be defined), not tied to any specific subsystem, is > required to share the EDID parser. That structure won't be exported to > userspace. > > Helper functions will be implemented in the subsystems to convert between > that generic structure and the various subsystem-specific structures.
I guess. I don't really see a reason not to unify the structs too, but then I don't have binary blobs to pretend to be ABI-compatible with. > The mode list is stored in the DRM connector in the EDID parser. A new mode > list data structure can be added, or a callback function can be used by the > parser to give modes one at a time to the caller. > > 3D needs to be taken into account (this is similar to interlacing). Would also be pleasant if the new mode structure had a reasonable way of representing borders, we copied that mistake from xserver and have been regretting it. > Action points: > - Laurent to work on a proposal. The DRM/KMS EDID parser will be reused. I'm totally in favor of this. I've long loathed fbdev having such a broken parser, I just never got around to fixing it since we don't use fbdev in any real way. The existing drm_edid.c needs a little detangling, DDC fetch and EDID parse should be better split. Shouldn't be too terrible though. Has the embedded world seen any adoption of DisplayID? I wrote a fair bit of a parser for it at one point [1] but I've yet to find a machine that's required it. > *** Split KMS and GPU Drivers *** > > Goal: Split KMS and GPU drivers with in kernel API inbetween. > > In most (all ?) SoCs, the GPU and the display controller are separate > devices. Splitting them into separate drivers would allow reusing the GPU > driver with different devices (e.g. using a single common PowerVR kernel > module with different display controller drivers). The same approach can be > used on the desktop for the multi-GPU case and the USB display case. > > - OMAP already separates the GPU and DSS drivers, but the GPU driver is > some > kind of DSS plugin. This isn't a long-term approach. > - Exynos also separates the GPU and FIMD drivers. It's hard to merge GPU > into display subsystem since UMP, GPU has own memory management codes. > > One of the biggest challenges would be to get GPU vendors to use this new > model. ARM could help here, by making the Mali kernel driver split from the > display controller drivers. Once one vendor jumps onboard, others could > have > a bigger incentive to follow. Honestly I want this for Intel already, given how identical Poulsbo's display block is to gen3. > *** HDMI CEC Support *** > > Goal: Support HDMI CEC and offer a userspace API for applications. > > A new kernel API is needed and must be usable by KMS, V4L2 and possibly > LIRC. There's ongoing effort from Cisco to implement HDMI CEC support. > Given > their background, V4L2 is their initial target. A proposal is available at > http://www.mail-archive.com/linux-media at vger.kernel.org/msg29241.html > with a > sample implementation at > http://git.linuxtv.org/hverkuil/cisco.git/shortlog/refs/heads/cobalt- > mainline > (drivers/media/video/adv7604.c and ad9389b.c. > > In order to avoid API duplication, a new CEC subsystem is probably needed. > CEC could be modeled as a bus, or as a network device. With the network > device approach, we could have both kernel and userspace protocol handlers. I'm not a huge fan of userspace protocol for this. Seems like it'd just give people more license to do their own subtly-incompatible things that only work between devices of the same vendor. Interoperability is the _whole_ point of CEC. (Yes I know every vendor tries to spin it as their own magical branded thing, but I'd appreciate it if they grew up.) [1] - http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/modes/xf86DisplayIDModes.c - ajax
