No subject

default modes. This is the list that is always in the modepool, with 
special modeflags.

> - hw/xfree86/modes/xf86EdidModes.c

How RandR deals with these is up to RandR code. Due RandRs unique 
design, drivers have little to no control over this.

> I don't understand which of these files define modes for which purpose.
> I can only see one reasonable purpose, to provide modes for the user
> that are not explicitly defined by EDID from the display devices.
> 

Before 2006, before code from bug #5386 was added, the modes in those 
few files, and the ones the user specified in the config file, were the 
only modes that were possible.

> In these lists some of the more exotic (but probably more often used
> in the future) modes are either missing (i.e. 1600x900, 1920x1080) or
> represented by different modes (like 1366x768 by 1360x768).

They do not need to, in general, any more.

> Additionally, xf86EdidModes.c has special code for handling some of the
> more weird cases (e.g. the infamous 1366x768), but AFAICS the code is
> only used for analyzing the EDID data.

Which seems quite valid. If drivers have knowledge about more modes, 
then they should have some or another way to tell RandR what modes given 
monitors support.

> In my experiments 1360x768 is interpolated to 1366x768, and thus looks
> dead ugly. 1366 itself is not dividable by 4, so in both GTF and CVT
> this results in 1368x768. I do not claim to understand how this is
> actually handled in both the Xserver and the displays :-/

Provided by EDID usually as the preferred mode, as these is the native 
resolutions. I hope that very little monitors claim to support this mode 
if this is not their native resolution.

Division is by 8 which is the character width in VGA. Anything VGA 
compatible is 8 pixels wide.

> So where should these additional modes go into? How to deal with modes
> that are not dividable by 4 (how about odd sized ones: 1680x945)?

There are two strategies here, and both depend on sane and correct 
mode validation, which, in a normal world, is driven by the driver.
Either the validation alters the mode and round according to the 
hardware's needs, and then the mode is passed through all validation 
again. Or the mode gets rejected.

There is no granularity (greater than 1) on vertical timing in vga modes 
when not using interlacing.

More on that over some weissbier and pizza in 5 minutes.

Luc Verhaegen.