Re: short display with 2.1.132-ac3, matroxfb and XF86_SVGA 3.3.3

Jon M. Taylor (taylorj@ecs.csus.edu)
Wed, 6 Jan 1999 12:09:12 -0800 (PST)


On Mon, 4 Jan 1999, Gerd Knorr wrote:

> On 4 Jan 1999, Jes Sorensen wrote:
>
> > I do not say you cannot, I do say there may be problems and therefore
> > people are lucky if it works - it is not guaranteed to work as in the
> > example with the Mach64 server.
>
> It is supported to work. If the X-Server does crazy things with the video
> board, it _must_ reverse these on exit and console switches.

That is just not possible in some cases.

> It works
> with the text console, why it should'nt work with fbcon too?

Because the text console video mode is *usually* a very simple
mode which the X server can always return to. But that is not guaranteed,
and if it is not the X server cannot be expected to figure it out. The
bottom line is that the fbdev drivers cannot make any changes to the video
mode anywhere once X has been run, or X will not know how to properly
restore the original video mode.

> It does'nt work (some versions of??) AccelX, becauce it _allways_ switches
> back to 80x25 text mode.

It does not matter if the problem is due to X blindly resetting to
80x25 textmode or to whatever mode the hardware was in when X was started.
The problem, which is that there's no mechanism for locking and
arbitrating access to the video card, remains.

> There are some boards where you can't read the current state (completely).
> With these the X-Server of cource has bad/no chances to restore things
> correctly. Blame your hardware. With such hardware you probably have the
> same problem if you try to switch between two X-Servers or between X and
> svgalib.

Nope. It can happen to the best hardware in the world. As long
as X and the fbdev drivers do not bother to communicate to each other what
they are doing to the video card, either can put the card in a state which
the other one does not know about and cannot determine on its own, and
which will cause the other to die horribly on a VT switch.

The write-only registers thing is a problem, but it _can_ be
tossed off by saying "buy non-crappy hardware". But MMIO reloc is a
feature of all PCI cards and is a plug 'n play complicance requirement.
If an fbdev driver does MMIO relocation, X will likely be unable to start.
If X does start and then does its own MMIO relocation, the fbdev driver
will oops when a VC it controls is switched to because the card's MMIO
regions will have moved out from under it.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/