By design, the current version of the console abstraction in StdLib does not
support function or arrow keys, nor does it support any form of input line
editing.
This is in the process of being rectified.
The hang shouldn't happen. Remediation of this is being pushed to the top of
the priority queue.
Currently, control characters are just another character on input.
Daryl McDaniel
"Software is like entropy.
It is difficult to grasp, weighs nothing, and obeys the second law of
thermodynamics;
i.e. it always increases."
-- Norman R. Augustine
________________________________
From: Tim Lewis [mailto:[email protected]]
Sent: Wednesday, July 25, 2012 5:10 PM
To: [email protected]
Cc: 'Shannon Lewis ([email protected])'
Subject: [edk2] Problems with gets() and arrow keys
If you use gets() and enter any of the arrow keys, you will get into a hang
condition. The root cause appears to be in da_ConRead, in daConsole.c.
Arrow keys (and various others listed in table 88 of the UEFI specification)
return ScanCode != 0 and UnicodeChar == 0 (except ESC, which I'll mention
later). This causes the code to go to:
if(iswcntrl(Key.UnicodeChar)) { // If a control character, or a scan code
break;
}
Since UnicodeChar is 0 for arrow keys, and iswcntrl returns TRUE for 0, this
will cause a break. By causing a break, no key will be placed in the output
buffer, which will give a read length of 0. Upper levels of the read code in
StdLib will interpret this as an EOF condition. So if you used code like:
char *x;
while ((x = gets(mybuffer)) != NULL) {
..process string...
}
You will hang. It tested under other environments and the arrow keys are
ignored. I suggest removing this section of code above
But this leaves other strange behavior with regard to control characters. Try
typing CTRL-C. Rather than ignoring it, it tries to print it. I added the
following code after NumEcho = 0;
if(Key.ScanCode == SCAN_NULL) {
NumEcho = 0;
if (iswcntrl (Key.UnicodeChar) &&
Key.UnicodeChar != CHAR_CARRIAGE_RETURN &&
Key.UnicodeChar != CHAR_BACKSPACE &&
Key.UnicodeChar != CHAR_TAB) {
Stream->UnGetKey.UnicodeChar = CHAR_NULL;
Stream->UnGetKey.ScanCode = SCAN_NULL;
continue;
}
This may not be the right way to handle this. In particular, there still seems
to be an issue with backspace. In implementations I tested (other than the
shell) backspace at the beginning of the line did nothing. But in the shell it
continues. Any help here?
Tim
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
