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/focus=55337

as well as possibly some other discussions from that period

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

One feature missing from the drm EDID parser doesn't mean the fbdev one is better in all cases.

Whoever takes over the merging process will have to check for missing bits anyways to avoid regressions.

quoted

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:)

The reason the drm has a more enhanced command line parser is to allow
for multiple devices otherwise it should parse mostly the same I thought
I based the drm one directly on the fbdev one + connector specifiers.

Dave.