Keyboard
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Keyboard
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.
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.
Re:Keyboard
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...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.
There are probably other such examples..
Re:Keyboard
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)?
Only Human
Re:Keyboard
Hi,
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
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.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)?
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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re:Keyboard
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?)
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?)
Only Human
Re:Keyboard
I'd just use set2 everywhere. Supporting both set2 and set3 is just extra work, and supporting set2 isn't that hard..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?)
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Keyboard
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 ...
Re:Keyboard
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?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).
Isn't the message queue a keyboard buffer for the application ?
Only Human
Re:Keyboard
Hi,
Cheers,
Brendan
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: How does it know to which user-interface code to send the keypress data?
A keyboard buffer only holds keypresses, while a message queue holds any data needed for communication between threads (which can include keypress information).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 ?
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re:Keyboard
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?
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?
Only Human
Re:Keyboard
Hi,
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
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).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?
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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re:Keyboard
I found out why it was printing the break codes.
it turned out that the
line didn't work.
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]
it turned out that the
Code: Select all
if(scancode != 0x80)
{
// keyboard code
}
Code: Select all
if(scancode & 0x80)
{
}
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]
Re:Keyboard
If by that you mean adding the ASCII value of the characters then what you have to do is something likeStephen 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.
Code: Select all
int var=10;
var += 'A';
Only Human
Re:Keyboard
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!
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!