Hello,

>     >> framebuffer were smart enough to drop into ddb while X is
>     >> running.
> 
>      m> This requires someone telling the driver about it.  The
>      m> problem with switching consoles is - if one console is in
>      m> graphics mode you need to tell the program hogging it to let
>      m> go, wait for an ack, then switch.
> 
> I guess you were answering another part of my silly rant maybe.  After
> a kernel panic you can't unsuspend XFree86 and ask it to do something
> for you. 

Well, a panic isn't the only thing that could drop you into ddb and
sometimes you will want to exit ddb again ;)
Anyway, in case of a panic you're obviously right, then we don't care
about any program hogging the console. But it still requires someone
telling the driver that a panic happened so it can do a forced switch.

> But it works fine on Solaris, and I think it worked at least
> for Xsun on NetBSD, right?

It works in Solaris because:
- the Xserver never switches video modes so nobody needs to force
anything back, the console driver just starts printing things
- XFree messes with the graphics hardware without telling anybody what
exactly it's doing so a forced switch is impossible for instance on
macppc where we don't have hardware specific wsdisplay drivers, only
ofb. On sparc64 we can do that though, but only as long as we have only
hardware dependent drivers which may change any moment - I have an
uncommitted hardware-independent OF-only driver here for instance, and
with some hacking in XFree's sparc64-specific PCI code it allows me to
use a Millennium I as 3rd head ;)
( of course the millennium doesn't have Sun firmware - I wish it did )

> It is a software-rendered console, so if wscons knows where the
> framebuffer is mapped and the bit depth, shouldn't that be enough to
> print ddb> if the kernel takes a panic while X is running?

As I said - that's only true as long as X doesn't mess with the graphics
chip. On a cg6 or ffb you can do that, but not with a mach64 for
instance because we don't know which kind of resolution/color
depth/framebuffer weirdnesses X would program. We could find out ( at
least in machfb ) and just rasops_reconfig() but that again requires
someone to tell us that we should.

have fun
Michael