On Mon, 2007-09-03 at 14:54 -0400, Adam Jackson wrote: > In either case, asking for the windows CD won't tell you what you want > to know. It will tell you sync ranges, when what you _want_ to know is > desired resolution and display type (as in, CRT, LCD, beamer, whatever). > Afterwards you can validate that against the sync ranges from the INF > file if you want, but really, either it'll work or it won't, and asking > for the CD won't make it work better. As someone who's done some work in the embedded space, I can see how it's possible that the device might return wrong information which is superseded by information found in driver updates. Firmware can't always be updated, so if the hardware does return with some error or new information is deemed important or necessary, that's usually done through some file update. What's the objective here? To come up with working ModeLines for the video card and video display combination? Don't Windows INF files contain additional information useful for coming up with those ModeLines that isn't available from the hardware (EDID)? How does Windows determine the valid resolutions for the same piece of hardware? When X can't come up with the same resolutions as Windows, is it because of a difference in computational algorithms? (someone mentioned how X gives width more importance) Is there no value to be gained from INF files? So there are four actors here: the monitor which supplies EDID information, information provided through some external file like the Windows INF, the user who might be able to make learned configs and the X server. I'm sure you all agree that the objective is a working display. Additionally, you might all agree that most, if not all, of the actions should be between the X server and the hardware, followed by additional external information (possibly provided as a file by the manufacturer or a database of information) and finally the user (whose sole purpose ideally is just to pick the setting which pleases him/her most). It seems people have to agree first on what the ideal objectives are and then discuss the technical aspects for achieving it. I agree with another poster who puts value to constructive criticism. May I also suggest that derogatory remarks or character attacks be lessened? Also, I hope the developers "in the know" will understand that in this community, some aren't as technically adept as they are but would still like to understand and learn, and no amount of post rereading is going to make it clearer IF there are information lacking or that needs clearing. -- Richi Plana -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
