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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
