The question this evening is whether the origin of various modes is interesting to the end user.

I've just spend a couple of hours hacking on RandR adding the ability to tag modes with an indication of how they were generated. Modes are tagged to indicate whether they came from the EDID data, the VESA specs, the config file or were specified by the user through the RandR extension.

I also tagged the 'Preferred' mode for the monitor; after all, when you plug a new monitor it, it's likely that you'll want to use the preferred mode if it has one. However, this little twist ended in sadness as I discovered that this particular tag may make it impossible to hook two outputs to the same CRTC; that's not possible unless the two outputs share the same mode, and a 'preferred' mode may not be preferred by the other monitor.

Obviously then, mode preference is a property of the output and not the mode. This, however, brings the whole exercise into question; is there any reason the origin of the mode should be of interest to the user? I suggest that really what you want is some metric that says how 'happy' the monitor would be with a given mode, and that's a relationship between the output and the mode, not a property of the mode alone.

I think there are four kinds of happiness here:

  1. Really happy - the monitor loves this mode and wants you to use it always
  2. Fairly happy - the monitor has a fondness for this mode and wouldn't mind using it
  3. Tolerable - the monitor is designed to handle this mode, although it isn't excited about it
  4. Forced - the monitor has been given this mode and wasn't asked to comment on it

Really happy is what you get when you read the EDID information (or LVDS stuff from the BIOS) and find a preferred mode or the native panel size. Fairly happy is for other modes discovered in the EDID data. Tolerable are modes which fit the required sync ranges but for which the monitor doesn't have any special love. And, if you construct a mode yourself and force it upon the monitor, it will attempt to use it.

Is there any reason to go into more detail than this? Do we need a 11-value scale so the driver can make more subtle distinctions between modes?