> 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. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
