From: Adam Jackson <ajax@redhat.com>
To: Takashi Iwai <tiwai@suse.de>
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 10:55:16 -0400 [thread overview]
Message-ID: <4F883E54.5020701@redhat.com> (raw)
In-Reply-To: <s5h3987vh60.wl%tiwai@suse.de>
On 4/13/12 10:29 AM, Takashi Iwai wrote:
> At Fri, 13 Apr 2012 10:14:46 -0400,
> Adam Jackson wrote:
>> 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?
Would be nice.
> 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.
I think you're trying to make me defend a position I wasn't taking...
>> 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.
I'm not disagreeing. I think common sizes should be available, and we
have code already that's intended to do that.
My issue with the list in the patch is it contains some nonsense. If
some of those more weird-looking sizes _do_ exist in the wild they
should be already present in EDID as the native size. For panels where
they're not native I have difficulty imagining anyone wanting to set
that mode intentionally. And for someone who really does want it they
have the ability to pass in arbitrary crap from userspace anyway.
1600x900 is reasonable to add to an "extras" list, because it is
actually common despite not being in DMT. I'm even willing to take
Windows as the example for what modes should be in the extras list. But
I'm not willing to take "I wish this was in a preset list" as the sole
justification.
- ajax
next prev parent reply other threads:[~2012-04-13 14:55 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
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 [this message]
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=4F883E54.5020701@redhat.com \
--to=ajax@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--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.