Hello,

>      m> telling the driver that a panic happened so it can do
>      m> a forced switch.
> 
> yeah, I was not imagining any switching involved.  I was imagining
> rather wscons would adapt to whatever mode XF86 had configured.

Well, we can - when we have a chip-specific driver. Only then.

>      m> - the Xserver never switches video modes so nobody needs to
>      m> force anything back,
> 
> yeah, it would be nice if XFree86 could work that way.  I understand
> XFree86 needs direct access to the chip for acceleration or whatever,
> but couldn't the mode-switching part be:
> 
>  1. ripped out or disabled and
>     a. replaced with a VESA modeswitcher
>     b. replaced with non-XFree86 chip-specific modeswitchers like
>        machfb

Not without a LOT of trouble. The mode switching is done by the chipset
drivers and VESA modes are PC specific.

> On an architecture with software-rendered characters, I don't see why
> XFree86 has to mandatorily change the video mode---isn't it done this
> way just a PeeCeeism where XFree86 expected the ``old'' mode would be
> a text-only mode?

Not quite. The firmware can not always set up the video mode we want,
for instance Apple OF 1.0.5 always uses 640x480 in 8 bit so without
hardware-specific video drivers we can't change anything. Oldish Sun
firmware supports higher resolution but also only 8 bit. And XFree is
meant to support arbitrary resolutions/video timings so restricting it
to VESA modes would be a major regression.

>  2. isolated into a separate userland tool that configures video
>     timings/sizes/bit depths.  this tool is:
> 
>       * graphics chip specific
>       * runs separately before the X server is invoked
>       * reconfigures text consoles as well as X

We could easily do that, at least for a handful chips.

> That is the same almost as XFree86 is now, except split into two
> binaries instead of one.

No, it's not at all the same. You'd still have to tear XFree apart.

> With #2, I guess whether XFree86 remains one piece or is split into
> two separately-invokeable front ends isn't so much the big deal as
> adding a call back into wscons after a mode change and inform it of
> the new screen geometry and color plane order and whatever.  wscons
> doesn't need to know how to change or read modes so long as XFree86
> keeps its idea of the mode current.

You're welcome to rewrite parts of XFree to do what you suggest.

have fun
Michael