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