<p>
NumLock has been a thorny "PC" issue from the days of the IBM 5150 of 1981, up
to today--maybe even longer. Anyway, I've hassled with how "correctly" to
handle it since at least 1985.
<p>
/***
Short digression, not to hijack the thread. In 1985 I wrote an ANSI/VT100
emulator for the original PC noted above. On a 4.77 MHz clock, etc., it was
necessary to write the code in assembler, and *under* the O/S (PC/DOS)--meaning
that even syscalls (int 0x21) took too long--I had to deal with the BIOS
directly, via its own interrupt calls, in order to keep 1200 baud from
overrunning the UART!
<p>
All the good action had to be in interrupt handlers, for keyboard and for UART
character arrival. Thus the mainline code was pretty simple:</p>
inton: sti /Interrupts on <br>
haltp: hlt /Put the processor into an enablled wait<br>
<p>
So then, on the BIOS (remember we were in 8088 Real mode, 1 meg address space),
you see keyboard hardware scan codes out of the k/b processor, not ASCII
chacacters, and you get to pick whatever you want for the actual character to
send to software. All keys and states, including NumLock and shiftstate, are
scancoded.
<p>
So, what to do about the a priori state of the NumLock key/LED when the
emulator is first invoked?
<p>
<i>and...</i>
<p>
What to do with the mainpad "<- Backspace" key as well? Should we send a ^H
(0x08) for this one, or a RUBOUT/DEL, 0x7f? (I chose ^H on historical grounds:
RUBOUT comes from paper tape, where to scrub a character, you literally rub it
out--punch out ALL the holes on that row. <Backspace> became a physical
backspace on hardcopy terminals a la the ASR-33 Teletype(TM).)
<p>
Plus, there is an actual DEL key, after all.
<p>
This digression is getting too digressive. To cut to the chase, I wanted for
the VT100 emulator to just arbitrarily behave as if NumLock (if currently off)
were on, <i> but at the same time, also turn on the keyboard LED to let the
user know this, </i> as opposed to <i> acting like NumLock and leaving the LED
off </i> if it was already off.
When the program was exited, the a priori NumLock state would be restored.
<p>
But I never actually got around to the second part.
***/
<p>
For the Solaris installer in 2006, it seems to me that if the target machine
has NumLock initially settable via BIOS, we should assume the user knows what
they want, and honor the setting. This would would of course mean being fully
k/b state sensitive.
<p>
If firmware cannot preset NumLock to a selectable state, my observation has
been that NumLock usually comes up on and LED on. If the user wants an arrow
action and gets a digit, it seems that this is less objectionable than wanting
a digit and getting an extended ANSI control command a la '<ESC>[247z'
displayed onscreen.
<p>
I had some comments about install system look and feel, but this post has
gotten rudely long...sorry.
<p><p>
Jim
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
