linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "K, Mythri P" <mythripk@ti.com>
To: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Corbin Simpson <mostawesomedude@gmail.com>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org,
	dri-devel <dri-devel@lists.freedesktop.org>,
	linux-media@vger.kernel.org
Subject: Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
Date: Fri, 25 Mar 2011 15:33:31 +0000	[thread overview]
Message-ID: <AANLkTinP3CUm3d8-RTG6NVniGh8MEwJ-unkggwZwpiZb@mail.gmail.com> (raw)
In-Reply-To: <4D8BC915.60400@gmx.de>

Hi Florian,

<snip>
>
>> So why should this be a common library? Most kernel code doesn't need
>> it. Or is there a serious need for video input to parse EDIDs?
>
> It's true that most kernel code does not need it as it is only useful for
> display output systems (and only the ones that can be connected to something
> sending EDID data) but it would be good anyway.
> Because sharing code that should fulfill the same purpose is always a good
> idea. But of course only if the scope is clearly limited as we don't want to
> end up with a mess that nobody dares touching again as it became to complex.
> So I totally agree that we should share the common stuff we all need and
> adding the extras one needs in the subsystem/driver.
> This is good because it looks like we'll have 3 display subsystems within
> the kernel for a long future and with a common library the same patch would
> not need to be done 3 times but only once. Or even more often if drivers
> have there private EDID implementation which I just throw out of mine to
> replace it later with a common one.
>

Precisely my point . Also if there are some bad TV models which
doesn't adhere to standard EDID, It would help to add quirks.
Anyone out there want to help me split the DRM code ? As i don't want
DRMer's to fret over changed code :).

Thanks and regards,
Mythri.
> Regards,
>
> Florian Tobias Schandinat
>

  reply	other threads:[~2011-03-25 15:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-22 17:44 [RFC PATCH] HDMI:Support for EDID parsing in kernel Mythri P K
2011-03-22 17:52 ` Mauro Carvalho Chehab
2011-03-22 17:58   ` Paul Mundt
2011-03-23 13:59     ` K, Mythri P
2011-03-22 18:32 ` Alex Deucher
2011-03-23  0:46 ` Dave Airlie
2011-03-23 13:40   ` K, Mythri P
2011-03-23 15:18     ` Jesse Barnes
2011-03-24  9:52       ` K, Mythri P
2011-03-24 19:06         ` Corbin Simpson
2011-03-24 22:43           ` Florian Tobias Schandinat
2011-03-25 15:33             ` K, Mythri P [this message]
2011-03-24 19:13         ` Guennadi Liakhovetski
2011-03-24 19:22           ` Alex Deucher
2011-03-25 13:46           ` K, Mythri P

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=AANLkTinP3CUm3d8-RTG6NVniGh8MEwJ-unkggwZwpiZb@mail.gmail.com \
    --to=mythripk@ti.com \
    --cc=FlorianSchandinat@gmx.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=mostawesomedude@gmail.com \
    /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).