OSDev.org

Posted: **Sun Aug 29, 2004 9:15 am**

actually, when the keyboard issue a "repetition" of the character (which only occurs with some keys ... not with 'SHiFT', for instance), another IRQ1 is fired, with the same makecode. So if you simply poll 0x60 and compare with the old value, you don't see the repetitions, but if you read 0x60 on IRQ1, you get them.

release codes are not needed in normal operation for most keys. they only get useful for "stateful" keys like SHiFT, Control, ALT, etc. or when using the keyboard as a gaming input device.

Posted: **Sun Aug 29, 2004 1:03 pm**

Pype.Clicker wrote: release codes are not needed in normal operation for most keys. they only get useful for "stateful" keys like SHiFT, Control, ALT, etc. or when using the keyboard as a gaming input device.

Except if you want Windows style behaviour for your space key and push buttons: put space done, the push buttons goes down, raise space, the onClick event is lauched...

There are probably other such examples..

Posted: **Mon Aug 30, 2004 12:03 pm**

Just asking. Do you set aside a fixed size buffer for the keyboard or let the user specify the buffer and its size (this seems the right way)?

Posted: **Mon Aug 30, 2004 9:12 pm**

Hi,

Neo wrote: Just asking. Do you set aside a fixed size buffer for the keyboard or let the user specify the buffer and its size (this seems the right way)?

My keyboard driver sends the keypress data as a message to the user interface code, which then sends this message to the active application (unless it's a global keypress). There is no keyboard buffer as the message queues do a similar job. The size of a message queue has no fixed limit.

If your OS doesn't allow several applications to be running at the same time, then you could use a fixed size buffer or a user specified buffer. In this case I'd probably use a largish (1 Kb) fixed buffer.

Cheers,

Brendan

Posted: **Tue Aug 31, 2004 11:55 am**

Ok something else now.
Do most of you use the set3 scancodes or the set2 scancodes, or do you try setting it to set3 and then default to set2 scancodes?
Are there keyboards in use today that do not support the set3 scancodes? or are these (not supporting set3) a minority? (effectively meaning is it worthwhile trying to support set2 scancodes?)

Posted: **Tue Aug 31, 2004 12:16 pm**

Neo wrote: Ok something else now.
Do most of you use the set3 scancodes or the set2 scancodes, or do you try setting it to set3 and then default to set2 scancodes?
Are there keyboards in use today that do not support the set3 scancodes? or are these (not supporting set3) a minority? (effectively meaning is it worthwhile trying to support set2 scancodes?)

I'd just use set2 everywhere. Supporting both set2 and set3 is just extra work, and supporting set2 isn't that hard..

Posted: **Tue Aug 31, 2004 12:34 pm**

afaik, scancode sets are a thing that the 8042 controller has to deal with. Whatever scancode set the keyboard use, the 8042 translates them to you, so i don't see an advantage of changing it ...

Posted: **Tue Aug 31, 2004 12:57 pm**

does that mean "stick to set2"? thats what the 8042 gives out isn't it?

Posted: **Wed Sep 01, 2004 12:25 am**

Brendan wrote: My keyboard driver sends the keypress data as a message to the user interface code, which then sends this message to the active application (unless it's a global keypress).

How does it know to which user-interface code to send the keypress data? or does this mean you have a fixed address in each task/process for keypress data?
Isn't the message queue a keyboard buffer for the application ?

Posted: **Wed Sep 01, 2004 1:12 am**

Hi,

Neo wrote: How does it know to which user-interface code to send the keypress data?

The user interface code is code that all applications send/receive messages to/from when dealing with user related devices (video, sound, mouse, keyboard, joystick, etc). The user interface keeps track of which application is "active" so that these devices can be shared by the applications in a sane way. The keyboard driver knows which user-interface to send keypress data to because it only knows about one of them.

Neo wrote: or does this mean you have a fixed address in each task/process for keypress data?
Isn't the message queue a keyboard buffer for the application ?

A keyboard buffer only holds keypresses, while a message queue holds any data needed for communication between threads (which can include keypress information).

Cheers,

Brendan

Posted: **Wed Sep 01, 2004 12:56 pm**

I just found out that BOCHS does not allow certain keyboard commands specifically the commands that work for set3 scancodes. I tried using the 'keyboard_type' option in BOCHS with 'MF' and 'AT' even with 'XT'

but there was no change, I kept getting an error until i thought of trying the code out on my PC and got the commands working.
Disabling the controllers AT-XT conversion also did not work in BOCHS but works on a real PC.
Is there any way around this (using a different romimage etc?) or is this a limitation of BOCHS?

Posted: **Wed Sep 01, 2004 8:47 pm**

Hi,

Neo wrote: I just found out that BOCHS does not allow certain keyboard commands specifically the commands that work for set3 scancodes. I tried using the 'keyboard_type' option in BOCHS with 'MF' and 'AT' even with 'XT' but there was no change, I kept getting an error until i thought of trying the code out on my PC and got the commands working.
Disabling the controllers AT-XT conversion also did not work in BOCHS but works on a real PC.
Is there any way around this (using a different romimage etc?) or is this a limitation of BOCHS?

The failure to do anything different after scancode set 3 is set is consistant with some keyboards (in general scancode set 2 is the only one that works on all keyboards).

Disabling the controllers AT-XT conversion is a limitation of Bochs. To fix it you'd have to rewrite/modify the keyboard and PS/2 controller chip source code. This would include changes to the way the emulator interprets keypresses from the host OS.

Cheers,

Brendan

Posted: **Thu Sep 02, 2004 3:58 am**

I found out why it was printing the break codes.
it turned out that the

Code: Select all

if(scancode != 0x80)
{
     // keyboard code
}

line didn't work.

Code: Select all

if(scancode & 0x80)
{
}

works better.

One other thing... How do you add a character to a variable?? I have tried lots of different ways, but I can't make it work.

Thanx,

[glow=yellow,2,300]Stephen[/glow]

Posted: **Thu Sep 02, 2004 11:33 am**

Stephen wrote: One other thing... How do you add a character to a variable?? I have tried lots of different ways, but I can't make it work.

If by that you mean adding the ASCII value of the characters then what you have to do is something like

Code: Select all

int var=10;
var += 'A';

will give you the 'K' or 75 (decimal)

Posted: **Thu Sep 02, 2004 2:47 pm**

When working in a multiprogramming environment, what happens with keyboard input? How does the kernel know which tty to send the keyboard input to? Is there only one global stdin file?

With a GUI environment, presumably the window manager would pick up all the stdin stuff itself since it usually draws on a pty and sends the input to the blocked "window" that is waiting for input, if it has "focus"...

Anyway, back to the multiprogramming disregarding window systems. If there are several processes blocked waiting for input, which process gets it, and how? Does it depend on the active tty? What if there are background processes all running on the "active tty" and all blocked waiting for input? First in first served? (E.g. first one to block gets it, then processes the input, the rest block waiting for more and are served in a sequential fashion?)

If you switch between pseudo terminals, ptys, does the kernel keep a pointer to the current pty, and the one that does a tty read on stdin and is "active" gets the line (assuming cooked/canonical mode)?

What if the user types ahead and no processes are waiting for input? Does the buffer eventually get full? Or does it get sent to a stdin file descriptor, and saved in a RAM disk file that acts as stdin? (Would that be a viable way of implementing keyboard input?)

Thanks for your insight!

OSDev.org

Keyboard

Re:Keyboard

Re:Keyboard

Re:Keyboard

Re:Keyboard

Re:Keyboard

Re:Keyboard

Re:Keyboard

Re:Keyboard

Re:Keyboard

Re:Keyboard

Re:Keyboard

Re:Keyboard

Re:Keyboard

Re:Keyboard

Re:Keyboard