From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: linux-fbdev@vger.kernel.org
Subject: Re: [PATCH 2/3] video: fbdev: Check Standard Timing against DMT
Date: Fri, 05 Dec 2014 11:41:06 +0000 [thread overview]
Message-ID: <548199D2.7010101@ti.com> (raw)
In-Reply-To: <1417643369-20603-2-git-send-email-davidu@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]
On 05/12/14 06:08, David Ung wrote:
>>> diff --git a/drivers/video/fbdev/core/modedb.c
>>> b/drivers/video/fbdev/core/modedb.c
>>> index 0b57c1df..858a97e 100644
>>> --- a/drivers/video/fbdev/core/modedb.c
>>> +++ b/drivers/video/fbdev/core/modedb.c
>>> @@ -497,6 +497,90 @@ const struct fb_videomode vesa_modes[] = {
>>> FB_SYNC_HOR_HIGH_ACT, FB_VMODE_NONINTERLACED,
>> FB_MODE_IS_VESA },
>>> }; EXPORT_SYMBOL(vesa_modes);
>>> +
>>> +const struct dmt_videomode dmt_modes[DMT_SIZE] = {
>>> + { 0x01, 0x0000, 0x000000, &vesa_modes[0] },
>>> + { 0x02, 0x3119, 0x000000, &vesa_modes[1] },
>>> + { 0x03, 0x0000, 0x000000, &vesa_modes[2] },
>>> + { 0x04, 0x3140, 0x000000, &vesa_modes[3] },
>>> + { 0x05, 0x314c, 0x000000, &vesa_modes[4] },
>>> + { 0x06, 0x314f, 0x000000, &vesa_modes[5] },
>>> + { 0x07, 0x3159, 0x000000, &vesa_modes[6] },
>>> + { 0x08, 0x0000, 0x000000, &vesa_modes[7] },
>>> + { 0x09, 0x4540, 0x000000, &vesa_modes[8] },
>>> + { 0x0a, 0x454c, 0x000000, &vesa_modes[9] },
>>> + { 0x0b, 0x454f, 0x000000, &vesa_modes[10] },
>>> + { 0x0c, 0x4559, 0x000000, &vesa_modes[11] },
>>> + { 0x0d, 0x0000, 0x000000, 0 },
>>> + { 0x0e, 0x0000, 0x000000, 0 },
>>
>> You've filled only some of the modes in this table. What's the logic which
>> modes are left out?
>>
>
> For DMT id 0xd, it has no STD 2byte id, no 3byte CVT code and no mode timings
> currently defined in vesa_modes struct.
> There is 80 DMT ids, but only 43 vesa_modes defined in fbdev. So I've left those
> entries empty. If we eventually have all the VESA timings, the last column could
> be eliminated.
Ok. So you added the modes to vesa_modes table that you were interested
in for your use case, and then filled the dmt_modes table with the modes
that were available in vesa_modes?
That's ok, I just want to understand the logic for which modes you added
and which you left out.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2014-12-05 11:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-03 21:49 [PATCH 2/3] video: fbdev: Check Standard Timing against DMT David Ung
2014-12-04 15:41 ` Tomi Valkeinen
2014-12-05 4:08 ` David Ung
2014-12-05 11:41 ` Tomi Valkeinen [this message]
2014-12-05 12:02 ` Tomi Valkeinen
2014-12-05 19:47 ` David Ung
2015-01-13 10:35 ` Tomi Valkeinen
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=548199D2.7010101@ti.com \
--to=tomi.valkeinen@ti.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.