[Xorg] The big multiconsole nasty

[Egbert Eich]

Keith Packard writes:
 > 
 > Around 18 o'clock on Jul 2, Egbert Eich wrote:
 > 
 > > We have never been able to support multiple ISA video cards.
 > > However RAC is an importand issue for a lot of PCI (AGP) graphics cards
 > > at least during initialization.
 > 
 > Ok; I didn't understand the limits of ISA card access; having 
 > (fortunately) never used a computer with an ISA video card...
 > 
 > And, of course we need some way to touch the VGA I/O ports on arbitrary 
 > video cards (I believe some S3 cards must be poked in I/O ports before 
 > they enable MMIO register access).

Not only S3 cards. Some others also. In fact the ISA support is only
100-200 lines of code on top of the general mechanism to ensure correct
routing of VGA resources.

 > 
 > > It is not only Intel that creates these problems. For many brand new video
 > > cards the VESA driver is the only option.
 > 
 > Right; you can either use the VESA X driver or the VESA fbdev kernel 
 > driver.  I mostly wanted to note that even "vendor" drivers can rely on 
 > the BIOS for mode selection, which is pretty harsh.

Right, when I saw this I felt sorry that I've ever done the int10 stuff :-/
It was ment to be a fallback solution. Now vendors have discovered it
as a feature.

 > 
 > > We should not need any PCI remapping if the kernel itself does the right
 > > mapping.
 > 
 > I thought the problem was that sometimes the kernel can't know what address
 > range is needed by an arbitrary card -- motherboard and video card bugs
 > sometimes mean that only a subset of the video memory ends up getting
 > mapped by the time the X server starts.  Without some way to ask the kernel
 > to remap things, it wouldn't be possible to fix this safely from user-mode.

The only problem of that kind I'm aware of was with an old S3 card
made by ELSA in the very early days of PCI. In order to extend the
video memory beyond the chip limits the board manufacturer added
some extra logic to board. With this the size of this memory range
as advertised by PCI config space was no longer valid.
If you want to know more you'd have to ask Harald Koenig who wrote
support for this driver for XFree86 3.x. 
I made considerable effords to be able to deal with cases like this
in the resource manager code of XFree86 4.x - however the driver had
never been ported.
Sometimes however there is need for drivers to override the generic
default settings made by the kernel: For example the 2.6 kernel seems 
to add WC to any prefetchable PCI memory range. This is how it should be.
However some Silicon Motion chips seem to have a HW bug that causes
the chip to lock up when setting the last 4K if video ram (just below
the MMIO ranges) WC.
I've never had a chance to do some deeper investigation of this problem
as I never saw it myself.

 > 
 > > What we may need is an IOCTL to set VGA routing on bridges. 
 > 
 > I'd sure rather see the X server not need to understand the whole PCI bus 
 > layout...
 > 

No, from an X point if view this is entirely irrelevant. From a hardware
driver layer this will be relevant on OSes that don't handle these things
thru the kernel. 
I would think 85-90 percent of the users can be served well without it.
The other 10-15 percent are users of older versions of Linux and users
of other less popular OSes.
We can either go and tell theese to go get lost and seek support 
elsewhere or we can add some reasonable fallback support for OSes
that don't provide these features.

Egbert.