On 03/12/14 23:49, David Ung wrote: > fbmon may generate mode timings that are out of spec of the monitor. > eg DELL U2410 has a max clock 170mhz but advertises a resolutions of > 1920x1200@60 in its Standard Timings, fbmon creates a mode using the > GTF timing calculation which gave it a 193mhz clock. The above is not exactly true with the previous patches, as fbmon doesn't calculate it with GTF, but looks it up from the DMT table. I have to say it's quite odd that the monitor advertises a mode it cannot display... > This patch checks to see if the mode can be supported by the monitor > by comparing against monspecs.dclkmax. I don't know about this patch... It looks a bit messy, and only handles a too high clock in the get_std_timing. We could as well get bad timing from get_est_timing() or somewhere else. And I don't know if get_std_timing() should even do such filtering in the first place. I'd say it's supposed to return the mode from the EDID block. Whether the monitor or the device actually supports the mode is a separate thing. Also, generally speaking, while I have no objection in fixing bugs in fbdev, I'd wish everyone just moved to DRM if at all possible. So if this starts turning into a bigger change, with possibilities for regressions, we have to consider if the fix is important enough. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
