linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Airlie <airlied@gmail.com>
To: linux-fbdev@vger.kernel.org
Subject: Re: [PATCH] fbdev: add a function to parse further EDID Detailed
Date: Thu, 21 Oct 2010 08:47:30 +0000	[thread overview]
Message-ID: <AANLkTim6CiyD0uk9x7Bu_o_6VM4_3nnrT5cMiSOL+Xhg@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1008200847020.6103@axis700.grange>

On Thu, Oct 21, 2010 at 6:26 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Thu, Oct 21, 2010 at 01:56, Dave Airlie <airlied@gmail.com> wrote:
>> On Fri, Aug 20, 2010 at 5:23 PM, Erik Gilling <konkers@google.com> wrote:
>>> Guennadi,
>>>    Not sure how you're using the edid but you can get all 4 DTDs by
>>> calling fb_edid_to_monspecs() then calling fb_videomode_to_var() on
>>> each of the entries in monspecs.modedb.  This is still lacking as
>>> modern monitors/tvs can have multiple EDID blocks.  My recent patch
>>> [1] is a proposal for addressing that.
>>
>> If someone is really interested in fixing up the fbdev EDID parser
>> they probably should look at sharing the drm EDID parser, its a lot
>> more complete and came mostly from the EDID parser in the X server.
>
> Funny, where do you think the fbdev EDID parser came from?

Guess where it came from 4-5 years ago, X moved on a long way since then.

> So I can only conclude that instead of updating/improving the fbdev one,
> a new one was duplicated/created, the DRM one? ;-)

Pretty much,

the fbdev edid parser had built up a lot of one-off fixes for various
scenarios, has had no major testing in non-embedded environments, it
was felt a clean start with the X one would have a better chance of
working without regressing the fbdev one.

I would like to provide the DRM one in a compatible manner to fbdev
users, its not a top priority for me but if someone really wants a
decent EDID parser that can handle modern monitors scenarios then I
would recommend investing in sharing that code than trying to make the
fbdev one do all the stuff it can't do now.

The fbdev edid parser last seen any major code updates in 2008 and the
fb layer was missing any sort of active maintainer which also led to
that decision.

Dave.

  parent reply	other threads:[~2010-10-21  8:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-20  6:48 [PATCH] fbdev: add a function to parse further EDID Detailed Timing Guennadi Liakhovetski
2010-08-20  7:23 ` [PATCH] fbdev: add a function to parse further EDID Detailed Erik Gilling
2010-10-20 15:12 ` Guennadi Liakhovetski
2010-10-20 23:19 ` Andrew Morton
2010-10-20 23:56 ` Dave Airlie
2010-10-21  8:26 ` Geert Uytterhoeven
2010-10-21  8:47 ` Dave Airlie [this message]
2010-10-21 14:08 ` Guennadi Liakhovetski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTim6CiyD0uk9x7Bu_o_6VM4_3nnrT5cMiSOL+Xhg@mail.gmail.com \
    --to=airlied@gmail.com \
    --cc=linux-fbdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).