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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
