487d404b1b
the signaled state of the apropriate event. As a side-effect of checking the event, it's signaled state is cleared if it was set. In efi_cons_getchar we used to wait for the apropriate event to be signaled before reading a character. This however does not work if we poll before reading the characteri, such as during autoboot. On a more compliant EFI implementation this resulted in the behaviour that hitting a key during autoboot would stop the countdown, but would then wait for a new character to arrive instead of reading the already pending key that stopped the countdown. The correct behaviour for efi_cons_getchar is to try to read a key and if none is pending, to wait for the apropriate event to signal the arrival of a new key. Note that with the previous behaviour, the second key would determine how the autoboot was interrupted. This would indicate that the first key got lost. This indicates that EFI does not necessarily maintain a queue of pending keys. FWIW... Approved by: re (carte blanche) French corrected by: various people :-) |
||
|---|---|---|
| .. | ||
| arch/ia64 | ||
| bootinfo.c | ||
| copy.c | ||
| delay.c | ||
| devicename.c | ||
| efi_console.c | ||
| efiboot.h | ||
| efifpswa.c | ||
| efifs.c | ||
| efinet.c | ||
| elf_freebsd.c | ||
| exit.c | ||
| libefi.c | ||
| Makefile | ||
| module.c | ||
| time.c | ||