Detecting PS/2 and AT

[ChazZeromus]

I am implementing some basic keyboard drivers for my kernel and I found a great ps/2 specification and AT. But the problem is, how can I detect what keyboard the user put into the machine?

[suthers]

I am implementing some basic keyboard drivers for my kernel and I found a great ps/2 specification and AT. But the problem is, how can I detect what the user put into the machine?

What do you mean 'what the user put into the machine', do you mean what key he pressed?
If it is, the keyboard sends a scancode to port 0x60, so by doing an inport on that port, you get the scan code, which you can then get the character by putting that value into a character map (an array...).
If your working on an x86 machine, IRQ1 is triggered when a key is pressed...
Jules

[ChazZeromus]

I meant what keyboard the user put in, sorry
How do I detect the type of keyboard that is connected to the system.

[bewing]

It's still a little confusing. Do you mean "what keyboard layout?" As in, whether it's a US, or a UK, or a Kanji keyboard? AFAIK, there is no way to know without having the user tell you.

[piranha]

I think he means what port it's plugged in.

-JL

[ChazZeromus]

Well, I'm reading the keyboard specification and when reading the keyboard status register there are bits that mean totally different things depending on the keyboard type, for example:

Bit 0: Output buffer status

0: Output buffer empty, don't read yet. 1: Output buffer full, can be read. (In the PS/2 situation bit 5 tells whether the available data is from keyboard or mouse.) This bit is cleared when port 0x60 is read.

[suthers]

Well, I'm read the keyboard specification and when reading the keyboard status register there are bits that mean totally different things depending on the keyboard type, for example:

Bit 0: Output buffer status

0: Output buffer empty, don't read yet. 1: Output buffer full, can be read. (In the PS/2 situation bit 5 tells whether the available data is from keyboard or mouse.) This bit is cleared when port 0x60 is read.

Sorry, I don't know the answer to your question, but what changes from keyboard type to keyboard type?
Also, are you attempting to write a poll driven keyboard driver?
Jules

[ChazZeromus]

Of course not! We'll some concepts in the speculation can be applied to through an interrupt handler.

We'll, I see that if you go to your device list in windows you can see what type of keyboard you have and the name of the model. So what does windows do that I can't do? Unless there is some insane driver that requires a super complex programming practice.

See? We'll at least windows can distinguish a PS/2 keyboard:

[Combuster]

Well, you will obviously know it when its an USB keyboard

[Osbios]

This parts are NOT Keyboard specific, they are Keyboard-Controller specific! The Keyboard-Controller belongs to the Mainboard.

My Tip:
Work around it! Seems a bit naive but actually you don't need the AT or PS/2 specific parts.

For example if you abandon pooling and use IRQs instead to get handle Keyboard and mouse, the IRQ (Keyboard=IRQ1, mouse port=IRQ12) will tell you where it comes from.

The AT standard is also very old and maybe you do not want to support it.

But I (and the Wiki) would be interested in a way to detect AT or PS/2 Systems.

@Combuster: You wont know about the USB connection of the Keyboard as long as the mainboard simulating a standard keyboard.

[Combuster]

@Combuster: You wont know about the USB connection of the Keyboard as long as the mainboard simulating a standard keyboard.

In that case you can kill the emulation. The mainboard should be correct enough that you can't detect the keyboard in both its USB and emulated version. That means either the keyboard must vanish (meaning its USB) or it stays and the USB version will not be there, at which point it is for all intents and purposes a PS/2 keyboard with a different plug.

[ChazZeromus]

This parts are NOT Keyboard specific, they are Keyboard-Controller specific! The Keyboard-Controller belongs to the Mainboard.

My Tip:
Work around it! Seems a bit naive but actually you don't need the AT or PS/2 specific parts.

For example if you abandon pooling and use IRQs instead to get handle Keyboard and mouse, the IRQ (Keyboard=IRQ1, mouse port=IRQ12) will tell you where it comes from.

The AT standard is also very old and maybe you do not want to support it.

But I (and the Wiki) would be interested in a way to detect AT or PS/2 Systems.

@Combuster: You wont know about the USB connection of the Keyboard as long as the mainboard simulating a standard keyboard.

You're saying I should just assume that the user has a standard keyboard connected and just live on? We'll I guess I'll stick with PS/2 then. Thanks anyways.

[Osbios]

I guess it is a bit cluttering because of the way names are "misused" in this case.

The first KBC was introduced with the AT System (http://en.wikipedia.org/wiki/IBM_Personal_Computer/AT) the second one with the AT successor the PS/2 System (http://en.wikipedia.org/wiki/IBM_Personal_System/2).

Before the AT System there was the XT System that used the Programmable Peripheral Interface (PPI). This was the ancestor of the KBC. Some parts of the KBC still work the same. I mention this because some documentations refer to the PPI or even explain PPI stuff for keyboard controlling. Some infos can be confusing and wrong for AT or PS/2 Systems. So you have to separate it.

I don't know much about the Keyboard types. Only this:
XT-Keyboard only send scancodes from keys. So you cannot communicate with them.
Other Keyboard types are the AT and the MF2.

And now back to your problem. You have varying informations on the programming of the AT and PS/2 KBC. But only parts of it are different. As far as I remember you can go around this parts. If you have a case where you think there is no other way then using functions that are different on both types I like to help.

TO ALL THE OTHER OS-DEVELOPERS: Come one... somebody has to know how to detect a AT or PS/2 System...

[Brynet-Inc]

I have several AT to PS/2 keyboard converters.. it would seem they're electronically compatible. (The converters have no internal logic..)

I don't think it's possible to differentiate between the two... from the programmers perspective the two devices are the same. (So why treat one different from the other?)

[Combuster]

Come one... somebody has to know how to detect a AT or PS/2 System...

Come on. Either there *is* an obvious difference, or its pointless to *make* the difference.

It's also tricky to assume there is someone with specific knowledge about that detail. Some questions will not give you an answer at all because the knowledge is not there, and this is hardly anybody's daily routine. At some point you will have to stop asking and go figure things out for yourself.