From: Adam Jackson <ajax@redhat.com>
To: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: Takashi Iwai <tiwai@suse.de>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
DRI Development <dri-devel@lists.freedesktop.org>,
Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.
Date: Fri, 13 Apr 2012 10:14:46 -0400 [thread overview]
Message-ID: <4F8834D6.6070601@redhat.com> (raw)
In-Reply-To: <CABVU7+v06cbPwHMp3D2V_nmY4eL6CgmdVOHUK6CG_hn0yy-pxw@mail.gmail.com>
On 4/12/12 7:09 PM, Rodrigo Vivi wrote:
>> CVT monitors _must_ accept GTF as well, EDID says so. So functionally
>> there's nothing wrong with the existing code.
>
> Actually the current code just check for gtf flag... so if a monitor
> is gtf2 or cvt this dmt modes are not being added.
Yeah, that's a bug. That's why I said it should be renamed
drm_dmt_modes_for_range and run unconditionally if we find a range
descriptor.
>> The thing you're trying
>> to sneak in here is a 1600x900 timing that doesn't correspond to
>> anything in DMT (at least, not in the copy of DMT that I have handy).
>> It's fine to want to add more modes - although I'm still unclear exactly
>> which machine you're trying to compensate for here - but not if it comes
>> by sacrificing the DMT list, which is there for a reason.
>
> There are customers complaining about lots of missing modes that are
> supported by windows and/or other drivers and we are missing. If this
> modes are ok on edid spec I se no problem in add them... ok.. I don't
> like hardcoded as well... I think we could find another way to invent
> this modes and use the cvt function to calculate timings... or
> something like that.
Why are they complaining, and why do you think you're obligated to care?
If it's not the native panel size and it's not a commonly found size in
the wild, why are we obligated to provide them for every user? Remember
that userspace has the ability to hand in modes from above.
>>> + /* 1024x576@60Hz */
>>> + { DRM_MODE("1024x576", DRM_MODE_TYPE_DRIVER, 46500, 1024, 1064,
>>> + 1160, 1296, 0, 576, 579, 584, 599, 0,
>>> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
>>> + /* 2560x1600@60Hz */
>>> + { DRM_MODE("2560x1600", DRM_MODE_TYPE_DRIVER, 348500, 2560, 2760,
>>> + 3032, 3504, 0, 1600, 1603, 1609, 1658, 0,
>>> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
>
> These ones came as request from HP.
> I'll check how they made that list.
1024x576 almost makes some sense, it's the fat-pixel version of
2048x1152. Except that you typically do fat-pixel modes like 1280x800
on a 2560x1600 screen because you're compensating for the host not being
able to do dual-link DVI (cough Intel), but 2048x1152 fits in a single link.
That 2560 mode appears to have been copied from the DMT list, but
seriously nobody does that size without doing reduced blanking. So if
we took my series to add the RB modes to the DMT list, and fixed that
bug I mentioned above...
- ajax
next prev parent reply other threads:[~2012-04-13 14:14 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-12 0:59 [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID Rodrigo Vivi
2012-04-12 16:03 ` Adam Jackson
2012-04-12 16:33 ` [Intel-gfx] " Takashi Iwai
2012-04-12 23:09 ` Rodrigo Vivi
2012-04-13 14:14 ` Adam Jackson [this message]
2012-04-13 14:29 ` Takashi Iwai
2012-04-13 14:35 ` Dave Airlie
2012-04-13 15:13 ` Takashi Iwai
2012-04-13 15:30 ` Alex Deucher
2012-04-13 15:41 ` Takashi Iwai
2012-04-13 15:52 ` Alex Deucher
2012-04-13 16:31 ` Adam Jackson
2012-04-13 16:48 ` Takashi Iwai
2012-04-13 14:55 ` Adam Jackson
2012-04-13 15:20 ` Takashi Iwai
2012-04-13 15:25 ` David Airlie
2012-04-13 17:16 ` Adam Jackson
2012-04-13 19:05 ` Rodrigo Vivi
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=4F8834D6.6070601@redhat.com \
--to=ajax@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=rodrigo.vivi@gmail.com \
--cc=rodrigo.vivi@intel.com \
--cc=tiwai@suse.de \
/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.