> Here's another question about consoles....  lkm's can replace existing
> support code, right?  With the right hooks, that is?  Would it be possible
> to create an lkm containing dt to replace the default console driver?
> 
> Of course, this still leaves the obvious questions, namely how would X
> take over the console (or better yet, take over a single virtual console),
> and how to require a password on the console in multi-user mode.

A general question to all: why does everyone want dt in the kernel?

I use a NetBSD/i386 system at work, and I prefer dt to pcvt. Besides the
annoying fact that the "switch screens" keys are different, they
basically do the same thing.

The main reason I've heard for wanting it in the kernel is so you get
the multiple screens at boot. Just set /etc/tty's up to, instead of
running getty on ttye0, run dt set to ask for passwords. Someone who
cares can set this up this afternoon. :-)

Having set a system up under both schemes, I much prefer dt. It took
me a frustrating while to get pcvt going (the apparent lack of a
port-i386 equivelant of the faq on puma didn't help either). With
dt, I just downloaded a binary, and away I went. I think dt, outside
the kernel, is an easier program for a novice to start with.

The one thing pcvt has which might be nice is the ability to key-switch
between an X session and a text screen.

Thing pcvt LACKS are dt's scroll buffers, the mouse pointer, and the
ability to copy and paste between screens. I REALLY miss the copy and
paste ability. 

The problem with putting these features into the kernel is there is no
standard. I mean that it's ok for a user program to decide that
command-c is copy, and command-v is paste. But the kernel shouldn't.
Such a policy choice has been deliberately removed from the kernel over
the years.

Oh, I really miss the copy and paste ability.

Also, UNIX has no standard copy buffer. Though X has a copy buffer,
it's an X thing. For us to be able to copy and paste between screens,
that buffer has to be changed somehow by the kernel. Gross. Or else we
have to have multiple copy and paste commands, one say is the X
standard, and the other is the dt-in-kernel one. Woe is the user who
copies text into the wrong buffer.

Did I mention I really miss the copy and paste ability when using pcvt?

To do this integration right, we have to change way too much code. Or
we have to do a partial integration. I'd really miss some of the dt
features which would cause problems.

So rather than sound like a party-pooper, let's figure out what people
really want from dt-in-kernel. We might be able to do it differently.

Take care,

Bill