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

[Guennadi Liakhovetski <g.liakhovetski@gmx.de>]

On Fri, 17 Feb 2012, Daniel Vetter wrote:

> On Fri, Feb 17, 2012 at 12:25:51AM +0100, Laurent Pinchart wrote:
> > Hello everybody,
> > 
> > First of all, I would like to thank all the attendees for their participation 
> > in the mini-summit that helped make the meeting a success.
> > 
> > Here are my consolidated notes that cover both the Linaro Connect meeting and 
> > the ELC meeting. They're also available at 
> > http://www.ideasonboard.org/media/meetings/.
> 
> Looks like you've been all really busy ;-) A few quick comments below.
> 
> > Kernel Display and Video API Consolidation mini-summit at ELC 2012
> > ------------------------------------------------------------------
> 
> [snip]
> 
> > ***  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.

I'm certainly absolutely in favour of creating a common EDID parser, and 
the DRM/KMS implementation might indeed be the most complete / advanced 
one, but at least back in 2010 as I was working on the sh-mobile HDMI 
driver, some functinality was still missing there, which I had to add to 
fbdev independently. Unless those features have been added to DRM / KMS 
since then you might want to use the fbdev version. See

http://thread.gmane.org/gmane.linux.ports.arm.omap/55193/focusU337

as well as possibly some other discussions from that period

http://marc.info/?l=linux-fbdev&r=1&b 1010&w=4

> >   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.
> > 
> >   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).
> > 
> >   Action points:
> >   - Laurent to work on a proposal. The DRM/KMS EDID parser will be reused.
> 
> I think we should include kernel cmdline video mode parsing here, afaik
> kms and fbdev are rather similar (won't work if they're too different,
> obviously).

This has been a pretty hot discussion topic wrt sh-mobile LCDC / HDMI 
too:-) The goal was to (1) take into account driver's capabilities: not 
all standard HDMI modes were working properly, (2) use EDID data, (3) give 
the user a chance to select a specific mode. Also here a generic solution 
would be very welcome, without breaking existing configurations, of 
course:)

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/