Hi Kalle, the next step needed for colortext is proper keyboard input handling. So far, it can read scancodes and convert them to keycodes (much like scan codes, however, in an internal format that allows easy processing. The key is seperated from the state up/down).
As far as I can remember (I lost some mails between you and me, so it's difficult to trace it back), you had problems dealing with blocking at read. I think the proper way to go about it is to have a queue and a reader thread, that consumes the keyboard input from the kbd raw device. If the queue is full, it can drop them and beep, for example, or do something else (enlarge the queue, whatever). This way, the reading from the keyboard raw device, and the actual feeding of any reader of the colortext console are completely seperated, and all blocking problems are also seperated. The actual code to do this correctly wrt select() etc can be found for example in pfinet (ether and tunnel device), but also in the term translator. I think the queue should not actually hold keycodes, but the characters that end up to be read from the device. This keeps the trivfs reading side of the issue very simple, and also avoids some other problems. This means that the meta keys state handling happens on the side which puts the characters on the queue. The need for a queue is real, esp if you consider cases where a key expands into a string (in Linux this is possible, it's a convenient feature for some people, and it's easy to implement this if you have a real queue). Extended scan codes will be easy to deal with, as the keycode is only put on the queue if it is complete. I will probably go for this strategy, if nobody else wants to beat me in implementing it ;) Then we need keymaps. Do we take the ones from Linux? I think there are two projects, console-data and kbd-data, doe sanybody know what the respective status of these projects is (eg which one is preferred, or better suited for our needs?). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
