OSDev.org

I want to know If user pressed 'F8' key at my the bootloader so I don't know what types of keyboards are int the computer. The BIOS have a 0x00 as the ascii code int the keyboard buffer and then the scancode. A PS/2 keyboard can send the 'F8' key as 0x42, 0x0A or 0x3F a thought then I can first ask the PS/2 devise what scancode It uses and then check the if 'F8' key was pressed. My problem is that may comone press a key at (for example) a USB keyboard, How I supposed to know if the key pressed? The keyboard may have connected differently!

Hi,



Why do you want the user to press F8?

If you want to do something different during boot if F8 was pressed (e.g. suppress a splash screen and show the user initialisation messages) it's better to use something like "if control key is being held down" because you can do that without adding a "do nothing for a while in case user presses F8" delay and without worrying about the user pressing the key too early or too late. This can be done using "int 0x16, ah=0x02". Note: Windows does this wrong - typically (if I want to use safe mode or something) I have to reboot the computer about 5 times while rapidly pounding the F8 key until I actually get the timing right (and from what I've heard, it's significantly worse for Windows 10).

For detecting how many keyboards of which type are connected where; the hardware already provides "enumeration" for both the PS/2 controller and USB.

For determining which scancode set a PS/2 keyboard uses you can just ask the keyboard itself (but it's better to configure the scancode set to what you want without caring what it was previously).


Cheers,

Brendan

I know that. After about 3 second's of waiting for the user to read the logo on boot, I will first ask the PS/2 keyboard what type of sacncodes it uses then I will then check the whole bios keybord buffer and if the scancode match I will do some things. The problem is the USB keyboards that in now days are the most common. My code will be at the 1st stage of the bootloader so I haven't even load the kernel or enter protected mode! Is there any way to find (using the bios maybe) If some USB keyboard is present, how is their scancode for 'F8' key (I saw here that the 'F8' key on USB keyboards scancode is 0x65) and from which keyboard came every key?

Unless the BIOS supports USB keyboards or the USB keyboard supports PS/2 mode (and USB legacy support is enabled in the BIOS) then there's no way to access a USB keyboard at this stage in the boot process. Even GRUB and Windows are affected by this. If the BIOS does support the keyboard (or the keyboard can work in legacy mode and this is enabled in the BIOS) then it will appear as a standard PS/2 keyboard and you will handle it exactly the same way. The BIOS will combine input from all supported keyboards and deliver it as a single input buffer, you won't know which keyboard the input has come from. Later in the boot process you can enumerate the devices yourself and find what keyboards are present and configure them however you need, but in the bootloader you're reliant on the BIOS handling the keyboard for you and delivering the keycodes. Fortunately these days most BIOSes support USB keyboards.

TL;DR Either the BIOS supports the keyboard or it doesn't, there's nothing that you can do about this. When the keyboard is supported, you won't know the difference between USB and PS/2 keyboards and you'll see all attached keyboards as one keyboard. Later in the boot process you can figure out what keyboards are connected and configure them yourself.

OK, but...
A PS\2 keyboard will use 1 of the 3 scancode sets and the USB keyboard?
If I receive a 0x42 will be 'F8' (PS\2 scancode set 1), 'K' (PS\2 scancode set 2) or a backspace (USB scancode set) ?
I read the sometimes PS2 controller interprets the scancode set from keyboard.
Also will the BIOS convert USB scancode set ?
What happens when the PS\2 device is emulated by USB devices - BIOS? (how can I ask the "PS\2" keyboard what scancode set it uses)

Hi,



For BIOS, if there's a PS/2 keyboard in the first PS/2 port the firmware configures the keyboard to use scancode set 2, and enables translation in the PS/2 controller (for backward compatibility purposes with extremely old computers from before PS/2 existed) so that it converts scancode set 2 into scancode set 1. If there's a PS/2 keyboard in the second PS/2 port then firmware will probably ignore it.

For USB keyboards, the keyboards typically support 2 different protocols - one called "Report Protocol" and one called "Boot Protocol". Report Protocol gives you a packet of data, and the format of that data is described by a convoluted (but extremely flexible) description language (that's shared by other "Human Interface Devices", like mouse, joystick, etc). Boot Protocol is designed to emulate legacy PS/2 (without any support for any extra features that a keyboard might have); and in both cases the codes used for keys have nothing to do with PS/2 scan codes (e.g. "A" = 0x04, "B" = 0x05, "C" = 0x06, ..). In general; I'd expect that if "PS/2 emulation" is used then (at most) one USB keyboard will use Boot Protocol; and any other USB keyboards could be left configured for either protocol or not configured at all.

For UEFI the firmware can configure PS/2 hardware and USB hardware however it likes (there is no requirements or guarantees). The only thing that matters is that it implements the EFI_SIMPLE_TEXT_INPUT_PROTOCOL. This protocol supports internationalisation and gives you Unicode characters; and defines its own "scan codes" (that are completely different to anything any keyboard uses) where these scan codes are only used for special keys that have no Unicode character (e.g. cursor keys, home, end, insert, function keys, etc) and there are no scan codes for most keys. Note: I'd assume that (to make it easier to for "hybrid firmware" to support both UEFI and BIOS) a lot of computers probably set things up the same as BIOS would have when using UEFI.



If you receive 0x42 from the BIOS, then it'll be F8 (PS\2 scancode set 1), even though the keyboard itself will use PS\2 scancode set 2 (and would've sent the byte 0x0A, and the PS/2 controller would've translated it into 0x42).



For "PS/2 emulation" the BIOS has to convert USB codes into PS\2 scancode set 1. In theory, for the "PS/2 emulation" case the firmware should emulate all of the possible commands a PS/2 controller and a PS/2 keyboard would accept (including the "get scancode set" command); but in practice the emulation itself is typically extremely bad (barely able to support simple key presses reliably) and will probably do everything wrong. Because of this; an good OS should always disable "PS/2 emulation" in any/all USB controllers before attempting to touch the PS/2 controller and shouldn't assume things like the "get scancode set" command actually work.


Cheers,

Brendan