All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Deucher <alexdeucher@gmail.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 11:52:16 -0400	[thread overview]
Message-ID: <CADnq5_PJU-K3rX-Z7fvuB-zQeYWKbaXqa0Q2vZ7x2dEh_K1LaA@mail.gmail.com> (raw)
In-Reply-To: <s5hsjg7tz95.wl%tiwai@suse.de>

On Fri, Apr 13, 2012 at 11:41 AM, Takashi Iwai <tiwai@suse.de> wrote:
> At Fri, 13 Apr 2012 11:30:01 -0400,
> Alex Deucher wrote:
>>
>> On Fri, Apr 13, 2012 at 11:13 AM, Takashi Iwai <tiwai@suse.de> wrote:
>> > At Fri, 13 Apr 2012 15:35:04 +0100,
>> > Dave Airlie wrote:
>> >>
>> >> > 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.
>> >>
>> >> You guys still haven't answered the basic question, what HW is this broken?
>> >
>> > The reported problem is about HP laptops with i915 driver (no matter
>> > chip chip is) and several monitors with resolutions more than the
>> > laptop panel.
>> >
>> > The LVDS provides only the native resolution (either 1366x768 or
>> > 1600x900) and a few other VESA ones (1024x768, 800x600 and 640x480).
>> > Meanwhile, the monitor EDID doesn't provide such laptop-native
>> > resolutions.
>> > Thus, in clone mode, the only possible resolution is 1024x768 or
>> > lower.  That's the whole problem.  It's too low and doesn't match with
>> > 16:9 although both laptop and monitor panels are 16:9.
>> >
>> > HP wants the clone mode of the laptop-native resolution and/or a
>> > higher resolution with the right aspect ratio like 1280x720.  Neither
>> > work as of now unless you add the extra mode manually.
>> >
>>
>> One thing to be careful of is that some monitors (especially LCD
>> panels) don't like modes that are not in their EDIDs.  As such when
>> you try and set them you often get a wonky display or more often a
>> blank screen.  We used to add a lot of inferred modes to the mode list
>> in the xserver which resulted in a lot of blank screens when some odd
>> mode was picked as the best match for a cloned display.  The "fix" was
>> to only add the inferred modes on analog monitors which were more
>> likely to be able to support them.
>
> Thanks, it's good to know!
>
> Though, I still wonder whether adding inferred modes for 1366x768 or
> 1600x900 would cause any big problems.  On such monitors, 1360x768 or
> 1440x900 (or 1680x1050) are usually seen in the supported list.
>
> Of course, it's never 100% safe.  But not so bad odds?

Probably ok on recent LCD panels as long as rb cvt modes are mostly
used.  Just something to keep in mind.

Alex

  reply	other threads:[~2012-04-13 15:52 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 [this message]
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=CADnq5_PJU-K3rX-Z7fvuB-zQeYWKbaXqa0Q2vZ7x2dEh_K1LaA@mail.gmail.com \
    --to=alexdeucher@gmail.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.