Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
Adam Jackson
ajax at redhat.com
Fri Feb 17 11:42:34 PST 2012
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@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
More information about the dri-devel
mailing list