Bochs: CTRL-break key combination
johank
I am busy designing event handlers for keypresses like print screen,
pause etcetera. I check for the state of any modifier key (i.e. alt,
shift, ctrl) and then I catch the scancodes for printscreen/sys rq and
pause/break.
In Bochs 2.3.6, running under Windows XP proffessional SP 3, I use the
user key to enter e.g. alt-print. I noted that there is no such
combination for the pause/break key. While I can hit alt+pause/break,
shift+pause/break and just pause/break and start the desired event
handler, ctrl+pause/break does not trigger its handler. Typically, ctrl
+print does, so it's unlikely there is some issue with the ctrl key.
The code here is (still) simple:
if (scancode == 0x62) /* PAUSE/BREAK */
{
switch (keyboard_status)
{
case KBD_META_ALT:
panic(KERN_DEBUG, "ALT-BREAK");
break;
case KBD_META_CTRL:
panic(KERN_DEBUG, "CTRL-BREAK");
break;
case KBD_META_SHIFT:
panic(KERN_DEBUG, "SHIFT-BREAK");
break;
default:
panic(KERN_DEBUG, "PAUSE");
}
}
Are you aware of any issue regarding Bochs and the ctrl-break key
combination? Can I use the user key to send this combination to my OS?
Any other workaround?
thanks!
Johan
Rod Pemberton
news:36b6d516-208c-4765...@n35g2000yqm.googlegroups.com...
>
> I am busy designing event handlers for keypresses like print screen,
> pause etcetera. I check for the state of any modifier key (i.e. alt,
> shift, ctrl) and then I catch the scancodes for printscreen/sys rq and
> pause/break.
>
Most keys have a "make" and a "break" sequence. The "pause" key has no
break sequence. It only has a make sequence. The raw scancodes for "pause"
in hex (for an IBM AT 101 keyboard with AT (set 2) to XT (set 1) translation
enabled):
E1 1D 45 E1 9D C5
The base scancode value is 0x45 which is also used in the Num-Lock sequence.
With that said, you are probably wondering just where your 0x62 for pause
is. It's not there. 0x62 means you're using P2/2 (set 3) with no
translation:
# USB Set 1 X(Set 1) Set 2 X(Set 2) Set 3 X(Set 3) keycap
...
126 72 e1-1d-45 e1-11-0b e1-14-77 e1-1d-45 62 77 Pause
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html#ss10.6
I don't mean to be a "Debbie Downer", but use of set 3 is usually considered
to be a "no-no". Not using translation to set 2 is also usually considered
to be a "no-no".
The problem with set 3 is that many keyboards don't support set 3. Those
that do have bugs in their set 3 implementation. Legacy USB only supports
set 2... Implementation of set 3 was so problematic that Microsoft had to
drop support for set 3, but that was a number of years ago.
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html#ss10.5
I.e., there is a good chance that once your OS is running on somebody else's
real hardware, you'll have problems with the keyboard implementation. E.g.,
if I where to use my '80's era Samsung AT keyboard with your OS, I'd
seriously doubt that I'd have a working keyboard. I strongly suspect that
set 3 wasn't available at the time the keyboard was made. But, if I were to
use my recently made dasKeyboard, I'd suspect that there would be no problem
using set3.
> In Bochs 2.3.6, running under Windows XP proffessional SP 3, I use the
> user key to enter e.g. alt-print. I noted that there is no such
> combination for the pause/break key. While I can hit alt+pause/break,
> shift+pause/break and just pause/break and start the desired event
> handler, ctrl+pause/break does not trigger its handler. Typically, ctrl
> +print does, so it's unlikely there is some issue with the ctrl key.
Those special "combinations" really shouldn't be thought of as combinations.
Technically, they are separate "keys" but are reusing the same key as other
keys. In set 2, they generate separate distinct key sequences. Clear? If
you pressed "ctrl+A", you'd have a combination of keys. But, "ctrl+break"
is a key.
> Are you aware of any issue regarding Bochs and the ctrl-break key
> combination? Can I use the user key to send this combination to my OS?
> Any other workaround?
I suspect the issue is that the break key (historically) only generated a
make sequence. For set 3 to be compatible, that _probably_ means no
combinations with other keys (ctrl, alt, shift, etc.). But, don't quote
me...
Rod Pemberton
johank
> I don't mean to be a "Debbie Downer", but use of set 3 is usually considered
> to be a "no-no". Not using translation to set 2 is also usually considered
> to be a "no-no".
When I started coding my keyboard driver, I used set 3 because I
thought it was the most straightforward set to use; my PC supported it
and I thought it would be unlikely that my OS would appear on any
other PC than my own. I still agree on the first reason, but with VHS/
VIDEO2000/BETAMAX in mind that may not make much sense anymore. More
in particular, modern PCs (including my own) come with a USB keyboard.
And - lo and behold - someone showed interest in my OS coding work and
wanted to try out things at his own PC. So yes, I really should recode
to set 2, albeit without much enthousiasm because I still think set 3
is superior.
> > Are you aware of any issue regarding Bochs and the ctrl-break key
> > combination? Can I use the user key to send this combination to my OS?
> > Any other workaround?
>
> I suspect the issue is that the break key (historically) only generated a
> make sequence. For set 3 to be compatible, that _probably_ means no
> combinations with other keys (ctrl, alt, shift, etc.). But, don't quote
> me...
Actually, alt-break, shift-break and break alone work perfectly, it's
just ctrl-break that is problematic; hence I thought it might be a
Bochs-related issue. I would have tried on my last old PC with non-usb-
keyboard, but the floppy drive is malfunctioning and currently my OS
only starts from floppy :-(
thanks for your info anyway!
Johan
wolfgang kern
"johank" wrote:
<q>
</q>
I can't help with set3, I never used it because it's rare supported.
All my (Set2) keybords produce special codes for only two key-combos:
*CTRL-Break E0 46 after (E0)1D instead of
Pause E1 1D 45 E1 9D 45 ;break code implied
*ALT-Ptr 54 after (E0)38 instead of 'Print' E0 37
I haven't seen break code for CTL-BRK and ALT-Prt, but I may have
ignored it because I use it to terminate and sys-request, so it
could be the codes E0 C6 and D4.
All other keys wont change their scan-code on ALT/CTRL/SHIFT/CAPS/NUMLOCK.
btw: perhaphs not documentented:
MS-left E0 5B
MS-right E0 5C
MS-menu E0 5D
they also produce break codes.
Break codes just differ in a set bit 7.
As E1 occure only with Pause, I quietly ignore the next five bytes
and treat it like any other key (application defined function).
I use the preceeding E0 2A/E0 AA to indicate CRSR-block-keys
__
wolfgang
johank
> just ctrl-break that is problematic; hence I thought it might be a
> Bochs-related issue. I would have tried on my last old PC with non-usb-
> keyboard, but the floppy drive is malfunctioning and currently my OS
> only starts from floppy :-(
Thanks for all your comments. I managed to find a friend with an old
PC (with non-usb keyboard supporting set 3 and functional floppy
drive) and indeed ctrl-break works fine, so I suspect it is indeed a
Bochs issue. Nevertheless, I think it is wise to recode my driver to
use set 2 somewhere in the future.
Speaking of Bochs issues, I found a number of GPFs on the real
hardware that I never saw under Bochs, which is a bit annoying at
least :-|
Johan
J de Boyne Pollard
RP> key has no break sequence. It only has a make sequence. The
RP> raw scancodes for "pause" in hex (for an IBM AT 101 keyboard
RP> with AT (set 2) to XT (set 1) translation enabled):
RP>
RP> E1 1D 45 E1 9D C5
... which is of course two make sequences followed by two break
sequences, giving the lie to the statement that there's no break
sequence. The correct information is that the pause key on a PC/AT
keyboard is a sham. What the keyboard actually does in mode 2 is
pretend that the user has pressed CTRL-NUMLOCK, which was the "pause"
sequence on the PC/XT keyboard, and then released it, but in a way
that doesn't interfere with the shift state of the "real" CTRL keys.
"E1 1D/E1 9D" is the make/break pair for a (dummy) CTRL modifier key,
and "45/C5" is the make/break pair for NumLock.
Rosch's _Hardware Bible_ and Mueller's _Upgrading and Repairing PCs_
go into extensive detail on the PC keyboard hardware, and in a few
respects are superior to the most commonly quoted WWW references on
the subject.
Rod Pemberton
news:5f56cc19-9bea-4111...@j4g2000yqe.googlegroups.com...
RP> Most keys have a "make" and a "break" sequence. The "pause"
RP> key has no break sequence. It only has a make sequence. The
RP> raw scancodes for "pause" in hex (for an IBM AT 101 keyboard
RP> with AT (set 2) to XT (set 1) translation enabled):
RP>
RP> E1 1D 45 E1 9D C5
JdeBP> ... which is of course two make sequences followed by two break
JdeBP> sequences, giving the lie to the statement that there's no break
JdeBP> sequence.
I'm not sure how you came to that conclusion...
JdeBP> ... which is of course two make sequences followed by two break
JdeBP> sequences
The values reported have nothing to do with a "make" or "break" sequence.
I.e., you can't look at "E1 1D 45 E1 9D C5" and say any part of it is a
"break" or "make" sequence.
A "make" is when the key is pressed. A "break" is when the key is released.
The sequence for "pause" - when translated as stated above - only has a
"make" sequence: "E1 1D 45 E1 9D C5". It only occurs with a key press. No
sequence is reported for a key release.
JdeBP> The correct information is that the pause key on a PC/AT
JdeBP> keyboard is a sham. What the keyboard actually does in mode 2 is
JdeBP> pretend that the user has pressed CTRL-NUMLOCK, which was the "pause"
JdeBP> sequence on the PC/XT keyboard, and then released it, but in a way
JdeBP> that doesn't interfere with the shift state of the "real" CTRL keys.
Acceptable.
JdeBP> "E1 1D/E1 9D" is the make/break pair for a (dummy) CTRL modifier key,
JdeBP> and "45/C5" is the make/break pair for NumLock.
I think you've made a mistake here by calling those values make/break pairs.
From the hardware perspective, the entire sequence is "make" only. From the
software perspective, those values may appear to be "make" and "break"
sequences, but they aren't. Maybe you should clarify by calling them
"simulated software make" and "simulated software break", so that one knows
you aren't referring to the actual harware "make" and "break".
Rod Pemberton
Halicery
> "J de Boyne Pollard" <J.deBoynePoll...@Tesco.NET> wrote in messagenews:5f56cc19-9bea-4111...@j4g2000yqe.googlegroups.com...
Hi
This document (http://download.microsoft.com/download/
1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/scancode.doc) was a good
resource when I wrote my driver. Note 5 on page 22 says that Ctrl-
Break sends a different make/break code from Break (E0 7E in Set 2).
It looks like a 'normal' key to me..
Attila Tarpai
J de Boyne Pollard
JdeBP> ... which is of course two make sequences followed by two break
JdeBP> sequences, giving the lie to the statement that there's no
break
JdeBP> sequence.
RP> I'm not sure how you came to that conclusion...
The processes are called *reading* and *thinking*.
JdeBP> ... which is of course two make sequences followed by two break
JdeBP> sequences
RP> The values reported have nothing to do with a "make" or "break"
RP> sequence. I.e., you can't look at "E1 1D 45 E1 9D C5" and say
RP> any part of it is a "break" or "make" sequence.
Yes, one can. Read. Think.
JdeBP> "E1 1D/E1 9D" is the make/break pair for a (dummy) CTRL
modifier key,
JdeBP> and "45/C5" is the make/break pair for NumLock.
RP> I think you've made a mistake here by calling those values
RP> make/break pairs. From the hardware perspective, the entire
RP> sequence is "make" only. From the software perspective,
RP> those values may appear to be "make" and "break"
RP> sequences, but they aren't.
Wrong. Read. Think. I pointed you to two resources on the subject.
From the hardware perspective, the controller chip in the keyboard is
sending two make sequences and two break sequences down the wires, and
from the software perspective the keyboard device driver reads two
make sequences and two break sequences, and has to recognize CTRL-
NUMLOCK as "pause".
Rod Pemberton
news:6a00c0b1-0b22-4435...@26g2000yqo.googlegroups.com...
>
> This document (http://download.microsoft.com/download/
> 1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/scancode.doc) was a good
> resource when I wrote my driver.
> Note 5 on page 22 says
No, it says this:
"Note 5 Key 126 for Scan Codes 1 and 2:"
"This Key is not Typematic and has no Break Code (Pause on US keyboards)"
"Scan Code | Make | L-Ctrl or R-Ctrl + Make "
"1 | E1 1D 45 E1 9D C5 | E0 46 E0 C6"
"2 | E1 14 77 E1 F0 14 F0 77 | E0 7E E0 F0 7E"
If you read "Typematic Characteristics" section, it also says:
"Typematic is the term used for keys that will automatically repeat after a
specified time delay. In scan code 1 and scan code 2, key 126 is the only
key that is not Typematic. (This key is the only one that does not send a
break code as well). "
Note the "... does not send a break code ..." and "... has no Break Code"
statements.
> Note 5 on page 22 says that Ctrl-
> Break sends a different make/break code from Break (E0 7E in Set 2).
First. I believe by Break you meant Pause, and by Ctrl-Break you meant
Break (Ctrl-Pause).
Second. It seems my own notes use Ctrl-Break instead of Break or
Ctrl-Pause. Confusing isn't it? This was to remind me that "Ctrl" was
needed for the sequence. It's odd that you would've used those terms
though. They apparently aren't from the source you recommended.
Third. No, that's not what "Note 5" says. "Note 5" says it sends a
different "make" code for Pause and Break (Ctrl-Pause). It doesn't send
"break" code for either. First, see the quote above about "Typematic".
Second, compare "Note 4" and "Note 5". You'll see that for "Note 4" there
is a "Make" and "Break" column for Key 124 which handles Print Screen and
SysRq (Alt-Print Screen). You'll see that for "Note 5" there is a "Make"
column but no "Break" column for Key 126 which handles Pause and Break
(Ctrl-Print Screen). What this means is that the Pause and Break
(Ctrl-Pause) only send a sequence upon a key press or "make". There will be
no sequence sent upon a key release or "break".
HTH,
Rod Pemberton
Rod Pemberton
RP> E1 1D 45 E1 9D C5
JdeBP> ... which is of course two make sequences followed by two break
JdeBP> sequences, giving the lie to the statement that there's no
JdeBP> break sequence.
The MS document that Halicery pointed out, contradicts your claims. What do
you have to say about that?
RP> I'm not sure how you came to that conclusion...
JdeBP> The processes are called *reading* and *thinking*.
Oh, so you're claiming that you place no value or zero value on *doing*?
Well, that figures.
But, as for *reading* and *thinking*, I must assume they failed for you in
this case. Even the non-authorative MS document that Halicery pointed out
contradicts your claims. IIRC, you prefer secondary, poor quality, MS
documents over other more reputable and authorative primary sources, like
IBM. Yes?
JdeBP> ... which is of course two make sequences followed by two break
JdeBP> sequences
RP> The values reported have nothing to do with a "make" or "break"
RP> sequence. I.e., you can't look at "E1 1D 45 E1 9D C5" and say
RP> any part of it is a "break" or "make" sequence.
JdeBP> Yes, one can. Read. Think.
Read:
"Typematic is the term used for keys that will automatically repeat after a
specified time delay. In scan code 1 and scan code 2, key 126 is the only
key that is not Typematic. (This key is the only one that does not send a
break code as well). "
What do you think?
JdeBP> "E1 1D/E1 9D" is the make/break pair for a (dummy) CTRL
JdeBP> modifier key,
JdeBP> and "45/C5" is the make/break pair for NumLock.
RP> I think you've made a mistake here by calling those values
RP> make/break pairs. From the hardware perspective, the entire
RP> sequence is "make" only. From the software perspective,
RP> those values may appear to be "make" and "break"
RP> sequences, but they aren't.
JdeBP> Wrong.
Wrong? Really? Stunning claim! How so? Something wrong with the MS
document? What about other reputable sources like the IBM PS/2 tech. ref.
manual?
JdeBP> I pointed you to two resources on the subject.
Both, IIRC, are non-authorative. But, could you quote them? I don't have
immediate access to them, nor do I intend to obtain access to them any time
soon.
You seem to be indicating they present a different perspective from mine.
But, my perspective agrees with the documents for which I had access. And,
from Halicery, I just learned that my perspective agrees with the MS
document also. How many more do I need?
> From the hardware perspective, the controller chip in the keyboard is
> sending two make sequences and two break sequences down the wires
No. The keyboard, if implemented correctly, should be sending _one_ make
sequence and _zero_ break sequences for Pause, ditto for Break (Ctrl-Pause).
Each has it's own sequence with modifiers.
> from the software perspective the keyboard device driver reads two
> make sequences and two break sequences
You could do that.
Rod Pemberton
Maxim S. Shatskih
> documents over other more reputable and authorative primary sources, like
> IBM.
I prefer sources which are used in popular commodity OSes.
i8042prt source was in Windows WDKs (at least in some recent ones like 6001.18002 which is the Vista/Srv2008 SP2 WDK).
Linux also has a source for PS/2 keyboard driver.
--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com