> > Does that mean X can't restore it either, if it exits properly? Does
> > it mean that some information which would enable us to reset the card
> > is lost when X dies? Or does it just mean that the card has crashed,
>
> The Cirrus cards have situations where unless you know the cards current
> state you can't set a new state reliably. To make it more fun the registers
> are sometimes write only
Which is why the integrity of the register softcopies are so
important.
> > If the latter is the case, GGI/KGI won't help either!
>
> fbcon/KGIcon can help here providing all video control access goes through
> its kernel interface. The moment you run a non fbcon/KGI X server yes
> you lose again.
The situation actually is potentially a lot worse than before
fbcon. Since X expects the hardware to be in its pristine state, the
kernel drivers must restore *everything* on a VT switch. This is not
always possible. For example, the KGI S3 Trio64V+ driver (and several
others) switch the card to MMIO-only mode when the drivers initialize
themselves in order to properly allow for multiheading. If this is done
after X starts, big problems will occur.
Suppose you start X on one VC and then and then two fbcon drivers
(KGI or otherwise) are inserted at the same time and some VCs are remapped
to each for multiheading purposes. The first driver controls the video
card that X also is trying to control, and the second driver controls
another card. If you switch to the X VC, you have to reset the card X
thinks it is controlling back to non-MMIO mode or X will die horribly.
However, if you DO reset the card, the fbcon driver will itself die
horribly because it still thinks that it is in MMIO mode. If the second
fbcon driver was not MMIOed because the first one had been and there was
no need to do so to avoid a conflict (or because some cards cannot be
MMIOed at all), both video card will now be mapped to the same VGA IO
ports as the other and things will get REAL interesting. A locked system
is quite likely at this point.
What the above example illustrates is that the existing "everyone
reset everything to a known good state on a VT switchaway and we'll all be
able to play together" scheme just does not work in all cases. You cannot
do this without sacrificing some capabilities in the kernel. The kernel
drivers can talk to each other and the rest of the kernel to avoid
stepping on each other's toes, but X has no such ability.
> Thanks to the fbcon module interface its now about to become
> a matter of "slightly faster" v "slightly more kernel overhead/memory" by
> user choice - which is the ideal solution
Would that this were the case. See above. Also, if you use
X86_FBdev you will have to give up all accelerations except rectangular
blitting, because that is all the fbcon API supports. XAA will also be
history. You could enhance XF86_FBdev to have knowledge of
driver-specific acceleration ioctls, but that won't give you the direct
access necessary to implement XAA efficiently.
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.altern.org/andrebalsa/doc/lkml-faq.html