| From: | Marc Culler |
| Date: | 28 Aug 2000 at 14:56:32 |
| Subject: | AMIOPEN: Serious problem |
I think the elate keycode cooker is seriously broken.
First of all, the documentation on the cooker
(/dev/keyboard/cooked/usr.html) is terrible.
Second, the cooking table that comes with the SDK is really screwy.
Here is a sample of the multibyte sequences that it sends for
the function keys and arrow keys when the terminal is in raw mode:
F1: ESC 5b 31 31 7e
F2: ESC 5b 31 31 7e
F3: ESC 5b 31 31 7e
F4: ESC 5b 31 31 7e
F5: ee 80 85
F6: ee 80 86
F7: ee 80 87
F8: ee 80 88
F9: ee 80 89
F10: ee 80 8a
UP: ee 80 a1
DOWN: ee 80 a2
LEFT: ee 80 a3
RIGHT: ee 80 a4
What is wrong with this, apart from the fact that it is completely
random and non-standard and uses five bytes in some cases where two or
three would suffice? The byte ee is being used to introduce a
multi-byte sequence of variable length. In other words, it is an
escape character. That is the job of ESC. I don't see any need to create
a new escape character. Besides, it seems like a bad idea to just pick a
number greater than 128 and use it as an escape character. Nowadays
those bytes may have other meanings. In the Latin-1 encoding the
byte ee is used for the circumflex i. If you randomly decide to use
ee as an escape character then you have removed the circumflex i from
somebody's alphabet. That seems like a dumb thing to do.
Of course one could just write a new cooking table, if one could
figure out the documentation. But then other applications that depend
on the current table one will break. I am thinking of the shell, which
obviously makes use of the arrow keys for its history.
AMIGA folks: Please have a look at this. At least explain the reasoning
behind this setup.
- Marc
Subscribe/Unsubscribe: open-request@amiga.com
Amiga FAQ: http://www.amiga.com/faq.html