Re: console plans

[Roland McGrath]

> I am preparing for the console server

You're the man.

> * A kernel driver to get the keyboard events from.  To reduce kernel code,
>   raw scan code events will be consumed in the ix86 version.
>   Status: GNU Mach can provide them, I have a hack for OSKit-Mach here that
>   needs to be polished and integrated into the source (a cheesy kbd device
>   that sets keyboard in raw mode when being opened).

Can you show me your hack?  The path of righteousness is to add proper ps2
(and usb, for that matter) drivers to the oskit.  I would do that right
quick if I had an x86 test machine.  

>   I don't remember if it works or if there are bugs, if there are bugs in
>   the mem device in OSKit-Mach I have fixed them locally and can submit a
>   fix (in other words: works for me).

I think you found some mem bugs and I integrated fixes for them already.
Please check if you have anything else I should put in.

>   OSKit-Mach is completed (except that it doesn't behave 100% correct
>   on SMP systems), I have to polish it and submit the code for integration.

I would be happy to integrate that.  Leaving SMP until later is fine.

> The console server emits characters in the local encoding

That seems like the right model.  One could perhaps simplify by always
going with UTF-8 or something, but it makes sense to me that the
term<->console io should look like what term<->serial io would look like if
you had a local-language ASCII terminal attached to the serial port (some
of us still have actual terminals, though I left my last one behind).  (But
maybe your implementation for PC scan codes should go to Unicode internally
and use libc's iconv code to produce the local format.)

I'm not sure what you have in mind when you say "Unicode support is not
feasible".  As far as I am aware, all of the POSIX.1 io and terminal
interfaces are described in terms of byte-oriented io.  So to meaningfully
do io through term, it has to be delivering a byte-oriented encoding such
as UTF-8.

> The only input driver that will be initially supported is of course the PC
> keyboard driver, which translates PC keyboard raw scan codes into
> characters.  This will require a configuration file with a translation
> table.

I don't have much opinion about the details of this, except that of course
we should have at least every feature people like from every other system.
My main thinking is don't write a new one if you can possibly avoid it.  If
not implementation code, there has got to be at least a file format and
tool interface that we can grab from somewhere else and be compatible with.
What about xkb?

A wacky idea that occurs to me is maybe you could write an iconv module for
PC scan codes and use the libc iconv functions to convert from that to some
local or universal encoding.  I guess that doesn't deal with special
features bound to key sequences that don't ordinarily translate to unique
byte values, unless you do something wacky like mapping sequences to some
special space of private Unicode characters that are reserved for your
hacks and you check for them specially.

I would like to get opinions on how this stuff ought to be from people
working on i18n for GNU as well.  As well as coding issues, I wonder what
framework makes the most sense for potentially supporting the moe complex
input methods used for the larger character sets.

> Here it is possible to either encode directly into the desired system
> encoding (like iso8859-1), or we could encode into an intermediate
> encoding (Adobe Standard Encoding, Unicode).  The advantage of having an
> intermediate encoding is that the configuration file becomes independant of
> the system encoding, which is a good thing.

We should definitely support hardware-related configuration as an
independent axis from desired local encoding.  

> The output half is similar.

Again, I don't care much about the details (I'll admit it, I just use X :-)
but my strong reaction is not to do a new one.  Obviously you won't do a
new font format, since there are existing fonts to use in existing formats.
But also for the tools interface and any configuration files and so forth,
compatibility with something that exists and people use is always a good
thing.  (People like it, there are configuration front-ends around, people
have their own scripts they can still use, etc.)

What ever happened about GGI?  It appears that project is dead.  Oh well.

> the dimensions need to be reported back to the user (SIGWINCH anyone?  I
> think we are missing support for that in the Hurd, and in term in
> particular).

It's all there.  term generates SIGWINCH when TIOCSWINSZ is done on the
terminal (or on the master half of a pty; that's what xterm does).  In
Unix/Linux console drivers, there is an implicit simulated TIOCSWINSZ done
by the kernel when the console is adjusted.  I think the appropriate thing
in your model is to have /hurd/console implement this part of the tioctl
interface, including sending SIGWINCH to the controlling pgrp--which should
be just the attached term translator.  You can add this to the hurdio
bottom half now and test it with term stacked on term: when it gets
SIGWINCH, do TIOCGWINSZ on the underlying term and propagate the change up
as S_tioctl_tiocswinsz does.  The whole pgrp signalling thing is sort of
icky and will get dicey if we ever have one term process handling multiple
terminals.  But it's there.

> Which leads me to the next configuration file needed, the mapping of
> characters (ASCII, iso8859-1 or whatever) to the encoding used in the BDF
> font (usually Adobe Standard Encoding, about which I have to get more info,
> but it can be an internal encoding, too).

This has got to already exist in some form for X to use.

> (An implementation detail: If you preload a font to the vga buffer, you
> can hard code an encoding, so it might be better to leave the decoding to
> the backend driver, inc ase it can shortcut it).

Ah, interesting point.  That seems worthwhile to avoid another conversion
layer in the io path.  

> The generic code will deal with virtual terminals, generic screen savers,
> and similar stuff (like displaying a status bar or a clock).  That is the
> place where you put all the gimmicks.

A built-in VNC server would be nice (and of course it should be possible to
run it so there is no real device, just VNC).  Hmm, perhaps it should in
general be possible to use multiple output backends, e.g. duplicating
output to two different video adapters for two displays.  (You could even
add adjacent multi-head support as well as just duplicate head
support--just give each backend a clipping region.  Another idea is
multi-head configurations where different heads, or groups of adjacent
heads, display different virtual consoles.)

What about DPMS?  If generic screen-saver code decides it's time to blank,
it needs to tell the hardware-specific backend, which for VGA sends some
magic byte to an io port.

> I am not sure how virtual consoles will work.  I don't think just creating a
> new virtual console at every open is a good idea.  Instead, we should name
> them.  Maybe the translator should provide a directory, and accessing 1, 2,
> 3, etc (or even names) accesses the virtual console with that number
> (created on the fly if necessary).

I had been thinking about implementing unix98 ptys and that is pretty
similar.  It could be a generic translator for a virtual directory of
translated nodes created on the fly.

> What I am in particular not sure is how we would get a getty on such
> virtual consoles (surely we would use some /etc/ttys entry, maybe some
> support needs to be added there).

Nothing special happens on GNU/Linux or BSD.  It's just standard to list
several virtual terminals in ttys or inittab (/dev/tty[1-8] on your
GNU/Linux system).  But it would make sense to have some kind of feature
where pressing some key would create a new virtual terminal and run some
command on it, and that could be configured to give you gettys on demand.

> I have some ideas I did not mention here, and I will see how many of
> these I get done in time.  I am sure I will not be able to implement all
> your ideas, but I would not like to miss a particular good one either.

If the code is structured well, then we always win by starting small and
adding bells and whistles later.