Re: [Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

From: Takashi Iwai <tiwai@suse.de>
To: Adam Jackson <ajax@redhat.com>
Cc: 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 16:29:43 +0200	[thread overview]
Message-ID: <s5h3987vh60.wl%tiwai@suse.de> (raw)
In-Reply-To: <4F8834D6.6070601@redhat.com>

At Fri, 13 Apr 2012 10:14:46 -0400,
Adam Jackson wrote:
> 
> 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.

Yeah, I saw your patches.  Should the further work base on them?

> >> 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?

Because it's his job.  And mine, too.  What a pity.

Yesterday I've read a news reporting that 1366x768 is the most
commonly used panel now, more than 1024x768.  And, 1600x900 is in the
second place of the modern laptop panels.

Windows and others do work with these resolutions on the same
monitor.  Why Linux driver can't?  Everbody (but developers) thinks
like that way.

> 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.

I don't think we need to support all wild modes, too.  But the _very_
common modes like 1366x768 and 1600x900 should be really supported as
default.

thanks,

Takashi