xserver: Branch 'master'

[Luc Verhaegen]

On Tue, Jan 30, 2007 at 12:06:49PM -0800, Eric Anholt wrote:
> 
> Sigh.  So I reviewed the specs for a bunch of hardware I have laying
> around:
> 
> - mach64 doesn't have this limitation.
> - g200 doesn't have this limitation
> - g400 doesn't have this limitation
> - savage4 has a much larger limitation, such that it won't be hit by any
> monitor I've encountered.
> - intel doesn't have this limitation
> - sis305 does have this limitation(1)
> - sis530 has a larger limitation, such that it won't be hit by any
> monitor I've encountered
> - rendition v2200 does have this limitation, but doesn't appear to
> support a high enough pixel clock
> - ple133 does have this limitation, and appears to support a high enough
> pixel clock
> - smi731 doesn't appear to have this limitation
> 
> (1) The docs aren't quite clear -- while it's a standard VGA register
> set, it also mentions the extra overflow register like on the 530,
> without documenting it.
> 
> So, in a review of a variety of hardware I have available to me, not
> counting generations of Intel chips separately, and not considering many
> more modern cards, 1 or 2 out of 10 chips I looked at might be able to
> encounter this limitation.  This is considering the 1680x1050
> non-reduced-blanking mode as the smallest mode I know of which would hit
> these limitations.
> 
> The generic code is enforcing chip-specific limitations that are,
> optimistically, applicable to 1 or 2 out of 10 chips.  For those chips
> not affected by this limit, they get to go to extra work to undo what
> this generic code helpfully tried to do, and may experience bugs in the
> process (we hit this on intel because our undo code stopped working as
> we were developing randr, and we apparently have issues with nonzero
> borders on SDVO and this code is the only cause of nonzero borders we've
> found).
> 
> As such, I'm quite inclined to leave my change as-is, and let the
> drivers for those few chips which have these strict requirements do the
> working around themselves.
> 
> Also, for the record, I don't recall looking at unichrome code other
> than looking at filenames to see what encoders you support, and
> providing review of EXA code.  Sorry if that offends.
> 
> -- 
> Eric Anholt                             anholt at FreeBSD.org
> eric at anholt.net                         eric.anholt at intel.com

The dotclock has absolutely nothing to do with this.

This isn't about the VGA limitation only, because there's always some 
limitation, and they are not at all hard to hit. Sometimes it's just a 
one or two bits more than VGA, so very easy to hit.

It is perfectly valid to take any modeline (like that 1680x1050) and 
replace H/VDisplay with say, 640x480. Then you will hit blanking 
limitations on almost all hardware. 

Sure, it doesn't make complete sense in these days of panel based 
monitors, where people want to use each and every digitally 
addressed pixel, but that shouldn't stop anyone from doing this.

Stern mode validation, with a possible overscanning workaround, on all 
drivers is what is needed. But this lack is historic and the fact that 
it's needed doesn't really change with the removal of this code.

You are however throwing blanking widths at hardware that most certainly 
doesn't support it and that did, unwittingly, depend on this code.

And you did remove this code without considering its use and without 
considering any of the consequences.

As far as further fallout goes:
* xf86-video-via and xf86-video-vga both have stern mode validation 
  already.
* xf86-video-tseng still needs to have better mode validation 
  implemented, but there are no extra blanking end bits over VGA there. 
  So the removal of this code does hit tseng directly.

I'm sure that many more of the old drivers will be regressed by this 
change.

Luc Verhaegen.