Default heuristics for variable-format displays

Adam Jackson ajax at redhat.com
Tue Sep 15 16:06:54 UTC 2009


In attempting to document how displays are expected to work in F12 [1],
I realized we still don't have a decent heuristic for some cases.

Broadly, displays are either fixed-format or variable-format.  FF means
you have some set number of pixels, like an LCD.  VF means you don't,
like a CRT.  (Projectors are often somewhere in between, we'll pretend
they don't exist for a moment.)  We get FF displays pretty much right,
since they tend to describe themselves well enough in EDID to figure out
what their native size is.  Some VF displays are polite enough to define
a preferred mode, and for that case we'll default to that.

But, many VF displays don't define a preferred mode.  How are we to
choose?  What's currently implemented will pick something along the
lines of "the largest available mode that matches our guess at the
physical aspect ratio and that fits in the card's DAC and memory
bandwidth limits".  Which is awful.  So I'm thinking something like (in
wretched pseudopython):

def mode_dpi_cmp(x, y):
	return cmp(abs(x.dpi - 96), abs(y.dpi - 96))

def mode_size_cmp(x, y):
	return cmp(x.width * x.height, y.width * y.height)

def best_mode(modes, dpi_known = True):
	l = filter(lambda x: x.refresh >= 72, modes)
	if l == []:
		l = modes
	if dpi_known:
		l.sort(cmp=mode_dpi_cmp)
	else:
		l.sort(cmp=mode_size_cmp)
	return l[0]

Which is _pretty_ good, except you'd kinda like to match aspect ratio if
you happen to know AR but not DPI.  Which is trivial to add, but starts
to be hard to read.

If anyone has ideas I'm all ears, but I'd like to get this implemented
sometime this week, so speak up.

[1] https://fedoraproject.org/wiki/Desktop/Whiteboards/HardwareHandling

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090915/14a3744a/attachment.sig>


More information about the fedora-devel-list mailing list