Re: console plans

[Roland McGrath]

> The console seems to be the natural place where you configure the system
> wide default encoding.  I am not sure how an alternative would look like.
> Where would the actual conversion took place if we were to use UTF-8
> unconditionally?

There would be no conversion on input in any part of the system except
console itself.  I think the locale interfaces require that the input and
output encoding be the same on a single terminal, so everything would in
fact be UTF-8 everywhere but at the console hardware itself.  Basically,
UTF-8 as the local encoding hard-wired.  But as I said, I don't think that
is really the right way to go because a) it's too easy :-), and b) we need
to handle other encodings anyway for serial communications.

> I thought there might be problems because the UTF-8 encoding is multi-byte. 
> I don't see a problem with transfering UTF-8 data through our system (that's
> what UTF-8 is about), but I thought term and maybe other things need to be
> UTF-8 aware to get the character boundary right.  

I don't think things are expected to be MB-aware at that level.  libc
expects byte-oriented io from the system with no special grouping
guarantees, and it does the MB decoding.

> It's an interesting observation though how this stuff is re-invented with
> every system, and kept seperately.

(Btw, "separate" is spelled with an "a".)  That's why I don't want to do
the same thing yet again.  The big attraction of using X data is that it's
the set of data describing the same hardware and the same features that we
will already have installed.  There are already handy tools for users to
select the configurations they like, etc.  Every other system not only has
a reinvented configuration system different from every other system's, but
in fact has two different ones and the second one (X) just happens to be
universally compatible among all systems.  So among all the choices, the
smallest possible leverage (no leverage at all) is in making our own new
one and the greatest available leverage is in using X.

xkb has a lot of stuff that is sort of specific to the X context.  I don't
think we'll want to use code from it or even all its configuration files,
but from the files describing hardware and dead keys and so on we can
extract the data (either parse the source or grok the compiled .xkm format).

> Again, I would like to preserve input compatibility with many.

Naturally.  But I would not worry at first about grokking a lot of formats
in our system per se.  It is enough to be sure that we have all the power
of expression of other systems.  Then people can write format converters
from other things that exist.  (Or, as you say, we can add new format
support directly when it is simple.)

> However, I also want to try to learn from the experiences.  As it turns out,
> interfaces like this hang around for a long time, and making a bad decision
> initially makes you look bad five years later.

Make that 10. :-)

> This is all very interesting stuff, but I think it is all stuff for other
> backend drivers.  Some code might be shared (vga code etc), and I will
> keep this in seperate files.  Likewise for svga support, and framebuffer
> terminals etc etc.

For a VNC server spying a real console, I would think it wants to expose
the bits from the actual frame buffer and thus needs to be specially
intertwined.  But the way to do it is just the duplicate-to-two-backends
plan with a virtual frame buffer updated by VNC in parallel with the real one.

> Currently, my standard answer to that is that we don't have APM support in
> the Hurd, which of course means that I have no clue how APM works.

I don't know a lot about APM either, but I think DPMS is not actually
directly related.  That is, I believe DPMS is an independent feature of
video hardware and monitors.  The APM stuff may know how to use DPMS,
but I don't think APM is required for DPMS to make sense.

> If it is only about doing some magic to an io port, I can add it easily
> (if I can find the docs on it, I will check freevga).

Hardware docs, I always forget about that notion. :-)
I was just reading the FreeBSD and Linux sources.