Detecting PS/2 and AT

[Osbios]

You have a 5pin Din and PS/2 connector converter. Both connectors use the same protocol.
And again IT IS THE KEYBOARD CONTROLLER ON THE MAINBOARD THAT MAKES THE BIG DIFFERENCE!!!

The hardware on the keyboard types (one seperate chip ON THE KEYBOARD) are really really equally. Expect the XT Keyboard and some possible scancodes you can set. I think that the keyboard type (AT, MF2, or something else) has nothing to do with the physical connector or the mainboard/KBC type (AT or PS/2).

Come on Combuster... 2326 Post and still not realizing that there is many pointless stuff eternalized in hardware.
And don't forget! The PS/2 connector included the mouse.

It is strange that so less infos about the keyboard is obtained by the OS-dev community. I mean what is one of the first thing you write for your OS...

Well lets try to get some infos together and put it in the Wiki.

I have some hardware (AT System with 5pin Din connector)
We could write a program (mini OS) and just test it.

[Brendan]

Hi,

Some random notes...

The normal terminology sucks. The "keyboard controller" is mostly a chip that controls 2 serial ports (and keyboards and mouses are just devices that plug into these serial ports), however these serial ports are not RS-232 or 16550/8250 compatible. To avoid confusion I call it a "PS/2 controller" because in modern machines it controls the PS/2 ports, and it may or may not control any keyboards (for example, you could have a bar-code scanner and a mouse).

There are differences between PS/2 controllers - some don't have a second PS/2 port, and some don't let you turn of the "scancode set 2 -> scancode set 1" translation for the first PS/2 port.

In the past I've written code that auto-detects the PS/2 controller type (while doing full initialization and fault testing), then auto-detects what type/s of devices are connected to the PS/2 port/s (if any). This code also allowed any device in any port (e.g. keyboard in second PS/2 port, mouse in first PS/2 port, a pair of keyboards, a pair of mouses, etc). Except for the "scancode set 2 -> scancode set 1" translation for the first PS/2 port (which can normally be disabled) there is almost no difference between the PS/2 ports.

For the keyboards themselves there's a huge variation between different keyboards. The old XT keyboards aren't worth supporting (they're extremely rare, and if they work at all they're probably worn out, and they're cheap to replace). All modern keyboards respond to the identify command and will return "something", but this is typically only enough to tell you that it's not a mouse. For e.g. there's no real way to determine if the keyboard is QWERTY or Dvorak, or if it's US, French, Spanish, Japanese, etc. However if you've got a full database of possible "scancode -> meaning" tables the byte/s returned by the identify command could be used to help narrow down the search for the correct "scancode -> meaning" table. If in doubt assume it's a QWERTY with US layout and ask the user. It'd also be good to provide a utility that makes it easy for users to create new "scancode -> meaning" tables and add them to your database (and possibly upload them to a central repository so other people can check them and use them)...

For the mouses, they're usually easy to detect - there's only about 4 different protocols with different packet sizes and distinctive characteristics, and most of them default to "two-button no scroll-wheel mode" (with magic sequences to enable more complex modes).

Lastly, it'd be good to treat PS/2 devices as "hot-plug" devices....

Cheers,

Brendan

[Combuster]

Come on Combuster... 2326 Post and still not realizing that there is many pointless stuff eternalized in hardware.

There is no such thing as pointless stuff in hardware. You only need to find the right use for it. And I think you don't understand what everybody has been saying over and over: If you can't find the difference, you should treat them as equal.

It is strange that so less infos about the keyboard is obtained by the OS-dev community. I mean what is one of the first thing you write for your OS...

We have what everybody needs to get started. If we want to do more, we RTFM, and so should you. I don't have all the answers, do you?

Well lets try to get some infos together and put it in the Wiki.

I have some hardware (AT System with 5pin Din connector)
We could write a program (mini OS) and just test it.

If you feel that's the only way to answer your question, please do go ahead.

[Osbios]

The normal terminology sucks. The "keyboard controller" is mostly a chip that controls 2 serial ports (and keyboards and mouses are just devices that plug into these serial ports), however these serial ports are not RS-232 or 16550/8250 compatible. To avoid confusion I call it a "PS/2 controller" because in modern machines it controls the PS/2 ports, and it may or may not control any keyboards (for example, you could have a bar-code scanner and a mouse).

But that would also be misleading. The KBC controls more then the PS/2 connectors. Like parts of the speaker, A20 Gate, ...

There are differences between PS/2 controllers - some don't have a second PS/2 port, and some don't let you turn of the "scancode set 2 -> scancode set 1" translation for the first PS/2 port.

I was assuming the disability of turning of the scancode translation was the fault of the USB-Legacy support. But I can be wrong.

In the past I've written code that auto-detects the PS/2 controller type (while doing full initialization and fault testing), then auto-detects what type/s of devices are connected to the PS/2 port/s (if any). This code also allowed any device in any port (e.g. keyboard in second PS/2 port, mouse in first PS/2 port, a pair of keyboards, a pair of mouses, etc). Except for the "scancode set 2 -> scancode set 1" translation for the first PS/2 port (which can normally be disabled) there is almost no difference between the PS/2 ports.

I also wrote a detecting routine for both ports independent from the combination of keyboard or mouses. But I'm very interested in the PS/2 controller detection! Do you still have it and can share it with us?

Lastly, it'd be good to treat PS/2 devices as "hot-plug" devices....

I do the same in software. But don't forget some board will go nuts if you unplug and plug PS/2 devices.

We have what everybody needs to get started. If we want to do more, we RTFM, and so should you. I don't have all the answers, do you?

But I didn't get hold of a "fucking manual" that answers all my questions. :*(
So my only hope is a old and wise OS-Developer... or something like that

[Brendan]

Hi,

The normal terminology sucks. The "keyboard controller" is mostly a chip that controls 2 serial ports (and keyboards and mouses are just devices that plug into these serial ports), however these serial ports are not RS-232 or 16550/8250 compatible. To avoid confusion I call it a "PS/2 controller" because in modern machines it controls the PS/2 ports, and it may or may not control any keyboards (for example, you could have a bar-code scanner and a mouse).

But that would also be misleading. The KBC controls more then the PS/2 connectors. Like parts of the speaker, A20 Gate, ...

You can't really call it the "miscellaneous crud controller"...

IMHO "PS/2 controller" is a good compromise between least confusing and most accurate, especially when you consider my main intention is to avoid confusing the "PS/2 controller" (e.g. an 8042 microcontroller or it's modern counterpart) with the controller chip that's built into the keyboard (e.g. an 8048 microcontroller or it's modern counterpart - the one that scans the keys/switches and talks to the PS/2 controller, and controls the keyboard).

There are differences between PS/2 controllers - some don't have a second PS/2 port, and some don't let you turn of the "scancode set 2 -> scancode set 1" translation for the first PS/2 port.

I was assuming the disability of turning of the scancode translation was the fault of the USB-Legacy support. But I can be wrong.

I've heard that the legacy keyboard emulation done by USB keyboards doesn't allow the scancode translation to be disabled. I've also heard that (at least for some motherboards) the legacy emulation doesn't reliably support other things (like resetting the computer). This is one of the reasons that it's important to find USB keyboards and disable the legacy keyboard emulation *before* doing anything with the PS/2 controller.

When I was doing my PS/2 code (about 4 years ago) I found that Bochs didn't allow the scancode translation to be disabled. I'm not sure if newer versions of Bochs allow scancode translation to be disabled or not, and don't know about other emulators. I also don't remember if any real computers had the same problem (I'm unsure about an 80486 computer I've got).

I do remember that my old 80486 computer only supported one PS/2 port, and that attempts to do things with the second PS/2 port actually effected the first PS/2 port (for e.g. an attempt to send an "identify device" command to the second PS/2 port would result in data arriving from the device connected to the first PS/2 port).

In the past I've written code that auto-detects the PS/2 controller type (while doing full initialization and fault testing), then auto-detects what type/s of devices are connected to the PS/2 port/s (if any). This code also allowed any device in any port (e.g. keyboard in second PS/2 port, mouse in first PS/2 port, a pair of keyboards, a pair of mouses, etc). Except for the "scancode set 2 -> scancode set 1" translation for the first PS/2 port (which can normally be disabled) there is almost no difference between the PS/2 ports.

I also wrote a detecting routine for both ports independent from the combination of keyboard or mouses. But I'm very interested in the PS/2 controller detection! Do you still have it and can share it with us?

I might still have it in some form or another (I've got a directory on one computer that has 21 different versions/prototypes of my OSs, some versions/prototypes have been lost, and some are on other computers). However, if I find it I doubt it'd help much - it's "OS specific" (it relies on a kernel API, etc that I no longer remember) and I threw it away for good reasons. Basically I thought it was good at the time, but that was 4 years ago and I've learnt enough since then to realize that it's well below my current standards.

I did look for this code but what I found was a later version of it; and in this later version I'd gone back to "no mouse allowed in first PS/2 port". IIRC there were a few reasons for this - problems with Bochs, problems with BIOSs that assume a keyboard is in the first PS/2 port and generate a "Keyboard error" and won't boot, and problems with Windows (either Windows 95 or Windows 98, I don't remember which) where Windows would lock up during boot if a mouse was in the first PS/2 port.

This code takes the following steps:

• - get PS/2 controller's configuration byte (command 0x20 sent to PS/2 controller)
  - send a new PS/2 controller configuration byte (command 0xA0 sent to PS/2 controller, then the configuration byte previously read with IRQs disabled and scancode translation enabled)
  - disable device A (send command 0xF5 to device A and wait for "ACK")
  - disable device B (send command 0xF5 to device B and wait for "ACK")
  - do device A interface test (command 0xAB sent to PS/2 controller)
  - do device B interface test (command 0xA9 sent to PS/2 controller)
  - reset device A (send command 0xFF to device A) and get results of BAT from device (if any)
  - reset device B (send command 0xFF to device B) and get results of BAT from device (if any)
  - allocate IRQs if any (IRQ 1 if "device A" wasn't disabled, and IRQ 12 if "device B" wasn't disabled) or kill the driver if both devices disabled

At every step there's time-outs and error detection, where (if there's a time-out or error) either the entire driver was killed (mostly in earlier steps), support for device A was disabled or support for device B was disabled. PS/2 controllers that didn't support the second PS/2 port failed at some stage in this (not sure which step, probably the "device B interface test") resulting in support for the second PS/2 port being disabled.

The end result was (hopefully) a 32-bit dword for each device containing the (one byte, 2 bytes or 3 bytes of) data it returned from BAT. There's also some code to correct this 32-bit ID for Bochs: apparently the mouse in Bochs only sent "ACK" and didn't send "ACK then 0x00" like a normal 2-button mouse, so I had some "%ifdef BOCHS" followed by "if(ID == 0x000000FA) then ID = 0x0000FA00" and "%endif" as a work-around.

Note: Unfortunately, if the PS/2 controller won't allow scancode translation to be disabled then it's impossible to reliably reconstruct the device's original data from the data you receive from the PS/2 controller.

Lastly, it'd be good to treat PS/2 devices as "hot-plug" devices....

I do the same in software. But don't forget some board will go nuts if you unplug and plug PS/2 devices.

Good "hot plug PS/2" support would include checking for "device removed" at regular intervals (e.g. every 5 seconds); and when you get a BAT (indicating "device inserted") from a device, checking if the device is the same device that was previously connected and (if it is) resetting prior state (e.g. so that if you unplug a keyboard and plug the same keyboard back in you don't lose the typematic rate, LED states, etc).

I only did part of this (ie. supported re-insertion of the same device, without supporting insertion of a different device or detecting "device removed") because I needed that to work - I was using old style KVM switch (a mechanical rotary switch, that disconnected and reconnected the keyboard, mouse and video when you selected a different computer).

We have what everybody needs to get started. If we want to do more, we RTFM, and so should you. I don't have all the answers, do you?

At this level of detail there is no single manual. Instead there's a large number of different datasheets from different manufacturers about different controllers and different chipsets, that all mostly (but not entirely) say the same things. I had limited information (more than most people collect I guess, but much less than "everything") but I doubt anyone could obtain all the information for all PS/2 controllers and still have enough enthusiasm left to read them all and find the differences.

I mostly did the programmer's equivalent of shaking a mysterious cardboard box trying to guess the contents - trial and error using educated guesses (based on the information I did have).

I should also point out that most OS developers don't do any of the things I do - they assume the PS/2 controller works, assume the BIOS's configuration is "good enough", assume a PS/2 keyboard (if any) is connected to the first PS/2 port (and assume it works), and assume a PS/2 mouse (if any) is connected to the second PS/2 port (and assume it works). Basically a lot of people just slap an IRQ handler onto IRQ1 and IRQ12 and do no testing or low level initialization. In this case there's plenty of information...


Cheers,

Brendan

[ChazZeromus]

Okay, now I'm having a hard time with grabbing scancodes. My question is, how would you grab a complete scancode set for a key(print or right control for example) without using a map to figure out the number of scancode sets for each key? I find this very aggravating. How would you grab a complete scancode without waiting to receive another one to complete a set by interrupt? I hear you can make the keyboard controller stop sending interrupts by disabling a certain bit. And then by re-enabling it you can get the next scancode without waiting for the interrupt to be fired up again. But I don't trust this method because it sound's somewhat slow.

[piranha]

When the IRQ fires, you read the scancode from port 0x60. Another IRQ will not fire until th latest scancode is read.

When you have the scancode, you compare it to a list of scancodes. That gives you the corresponding ascii value.

-JL

[Brendan]

Hi,

When the IRQ fires, you read the scancode from port 0x60. Another IRQ will not fire until th latest scancode is read.

When you have the scancode, you compare it to a list of scancodes. That gives you the corresponding ascii value.

Almost, but not quite: when the IRQ fires you get one byte of a (potentially) several byte sequence that corresponds to a scancode. I think this is where ChazZeromus is having trouble, in that he wants the entire sequence not just one byte.

@ChazZermus: When you get the first byte of the sequence you just remember that you got it; and when the next IRQ occurs you check if you got something beforehand. In this way you get one byte per IRQ and only need one byte per IRQ.

For a simple example, imagine something like:

Code: Select all

#define gotE0   1

int currentState  0;

keyboardIRQ:
    in al,0x60
    if(currentState == gotE0) {
        handleExtendedScancode(al);
    } else {
        if(al == 0xE0) currentState = gotE0;
        else {
            handleNormalScancode(al);
        }
    }
    sendEOI();
    iretd

You'd define more states for "got first byte of pause", "got second byte of pause", "got first byte of prntScrn", "got second byte of prntScrn", etc.


Cheers,

Brendan

[piranha]

Almost, but not quite: when the IRQ fires you get one byte of a (potentially) several byte sequence that corresponds to a scancode. I think this is where ChazZeromus is having trouble, in that he wants the entire sequence not just one byte.

Damn! I knew I missed something!

-JL

[jal]

@ChazZermus: When you get the first byte of the sequence you just remember that you got it; and when the next IRQ occurs you check if you got something beforehand. In this way you get one byte per IRQ and only need one byte per IRQ.

Indeed. The trouble lies perhaps in ChazZermus possible assumption that a multi-byte sequence can be any sequence of bytes, so that if you read the first, then the second instead of two at a time, you'd be lost interpreting whether it's one or two key presses. However, in reality that's not the case: multi byte sequences always have as the first byte a special code by which you can recognize you're doing a multi-byte sequence.

I recently recoverd some very old source code of one of my earlier OS-building attempts. I attached the file dealing with the keyboard. I don't vow for it being bug free or correct, but you'll get the basic idea from it. Especially check the HandleKey function.


JAL

[ChazZeromus]

Thank you, I'll look at that. I was thinking about looking at the linux kernel source(And I know exactly where the AT/PS2 keyboard drivers are!) but as everyone knows, navigating the source is like navigating a maze blind.

Here's what I've been trying to take a go at(It prints a message for debugging):

Code: Select all

void keyb_handler(struct idt_struct* _idt_reg)
{
	u8 scan;
	keyb_scan(&keyb_scancode);
	scan = keyb_scancode;

	
	switch(scan)//First handled specific ones
	{
	case 0xE1://Special keys always got this scancode first
		keyb_clearbuffer();
		keyb_mode = KBM_OTHER;
		break;
	case 0xE0:
		keyb_mode = KBM_SPECIAL;
		break;
	default:
		switch(keyb_mode)
		{
		case KBM_NULL:
			printk("Scan: %-cc8%%h|%h|%h%-rc%\r\n", scan, scan & (~0x80), (scan & 0x80) >> 7);
			break;
		case KBM_SPECIAL:
			printk("1 Set: %h\r\n", scan);
			keyb_mode = KBM_NULL;
			break;
		case KBM_OTHER:
			keyb_pushbuffer(scan);
			if(keyb_scancode_ptr == 2)
			{
				printk("2 set: %h, %h\r\n", keyb_scancode_array[0], keyb_scancode_array[1]);
				keyb_mode = KBM_NULL;
				keyb_clearbuffer();
			}
			break;
		}
		break;
	}
}

[ChazZeromus]

Sorry the bump,
But is the source file you gave me based on the keyboard specification that the wiki references, at http://www.win.tue.nl/~aeb/linux/kbd/?
But I thought that list of keyboard commands used in the source are the same as the AT list? Or are they PS/2 also?

[jal]

But is the source file you gave me based on the keyboard specification that the wiki references, at http://www.win.tue.nl/~aeb/linux/kbd/? But I thought that list of keyboard commands used in the source are the same as the AT list? Or are they PS/2 also?

It's PS/2, as you can see by the deactivation of the second unit. But I honoustly do not know exactly which reference I based it on, as it derives from an even older source that predates even the internet (or at least the one we are used to). I would not look too much at the specific commands used, as the comments show that I was quite unsure about e.g. resetting and such (it claims controller error in Bochs). I think the main value for you is seeing how I solved reading multi-byte sequences and the extended key stuff.


JAL

[ChazZeromus]

But is the source file you gave me based on the keyboard specification that the wiki references, at http://www.win.tue.nl/~aeb/linux/kbd/? But I thought that list of keyboard commands used in the source are the same as the AT list? Or are they PS/2 also?

It's PS/2, as you can see by the deactivation of the second unit. But I honoustly do not know exactly which reference I based it on, as it derives from an even older source that predates even the internet (or at least the one we are used to). I would not look too much at the specific commands used, as the comments show that I was quite unsure about e.g. resetting and such (it claims controller error in Bochs). I think the main value for you is seeing how I solved reading multi-byte sequences and the extended key stuff.


JAL

Well alright, that answered a few questions, but I still got some about scancodes.
Why is right control have a way different scancode than the left?
How can I get the same multiple input intervals for the pause key?

[Brendan]

Hi,

Why is right control have a way different scancode than the left?

Originally there were 2 control keys that gave the same scancode. Then they added extended scancodes (scancodes that begin with an 0xE0 byte) and gave the right control key it's own scancode (so you could tell which control key was pressed), but they did it in a way that made sense if you ignored the 0xE0 byte (because old software that was written beforehand ignores 0xE0). For example, left control is 0x14 while right control is "0xE0 0x14" (which gives backward compatible scancodes for the old software). The same is true for other keys, like left and right alt; and up, down, left, right, pgup, pgdown, end, delete, home and insert (which had scancodes on the numerics keypad but were given extended scancodes when they became seperate keys).

In a similar way the scancode for prntScrn is backward compatible with the scancodes for "left_shift + keypad_*", and the scancode for pause is backward compatible with the scancodes for "control + numLock" (where 0xE1 is strange because the new right control already used the 0xE0 byte).

Note: For all of the above I'm talking about scancode set 1 (or translated scancode set 2). For untranslated scancode set 2 it's the same with different numbers...

How can I get the same multiple input intervals for the pause key?

What do you mean by "multiple input intervals"? If you want to get a break code when pause is released (like normal keys) then you can't unless you use scancode set 3 (which isn't recommended)..


Cheers,

Brendan