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
