Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx/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
--
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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux