keyboard input
keyboard input
How do people like to handle keyboard input? I dont mean how the interrupt works, I mean where does it store the keystrokes? Is there some global buffer that it just puts them in until someone reads from it? I did some I/O programming in school, and thats how we did it, but we used the UART and never touched the keyboard interrupt.
Re: keyboard input
I guess you could buffer them but there is not really a reason to. Every time the keyboard interrupts the scancode is read from the port then it is added to the screen or whatever you want to do with it.As far as I know the keyboard does have a small buffer already built in.
Gizmic OS
Currently - Busy with FAT12 driver and VFS
Currently - Busy with FAT12 driver and VFS
Re: keyboard input
so i need to setup some kind of device system you mean? or does the input just go to the current running process?
Re: keyboard input
You have to set up a device driver to tell the PC what to do when it interrupts and what to do with the input
Gizmic OS
Currently - Busy with FAT12 driver and VFS
Currently - Busy with FAT12 driver and VFS
- Troy Martin
- Member
- Posts: 1686
- Joined: Fri Apr 18, 2008 4:40 pm
- Location: Langley, Vancouver, BC, Canada
- Contact:
Re: keyboard input
Are you in real mode or protected mode? There's a huge difference in keyboard input between the two and I'm afraid I can't help you with the latter.
Re: keyboard input
i havnt really started yet, just figuring things out. why would there be a difference in real mode and protected mode? don interrupts work the same?
- Troy Martin
- Member
- Posts: 1686
- Joined: Fri Apr 18, 2008 4:40 pm
- Location: Langley, Vancouver, BC, Canada
- Contact:
Re: keyboard input
No, in protected mode you don't have the BIOS interrupts (int 16h, int 10h, etc.) at your disposal. The BIOS is 16-bit, so it uses segment:offset stuff to use up to 1 MB of memory, where protected mode uses selector:32-bit offset to use up to 4 GB of memory. If you're just starting, start with real mode so you can use the BIOS.
That's my opinion, at least. It's wayyy easier to use the BIOS.
That's my opinion, at least. It's wayyy easier to use the BIOS.
- Troy Martin
- Member
- Posts: 1686
- Joined: Fri Apr 18, 2008 4:40 pm
- Location: Langley, Vancouver, BC, Canada
- Contact:
Re: keyboard input
Sure, it's possible, and probably just as difficult. I've never done anything other than monotasking so I'm not the most qualified person for the job. But you should read the Multitasking Systems article on the wiki.
- piranha
- Member
- Posts: 1391
- Joined: Thu Dec 21, 2006 7:42 pm
- Location: Unknown. Momentum is pretty certain, however.
- Contact:
Re: keyboard input
Each of my virtual terminals has a 256 character buffer in it. As keys are pressed, a character is added to the buffer of the current virtual terminal. When a process reads from the virtual terminal, it reads at buffer[0], and then all the following characters if there are any) are brought down to the previous position in the buffer (buf[5] goes to buf[4], etc). If there are no characters in the buffer, the process waits until there are.How do people like to handle keyboard input?
This is a simple, effective system to implement, and I can't make it miss any keystrokes. Just reading from the port on every read operation can make you miss keys.
This system is almost complete for me, but one thing I must still work out is what to do when there is an overflow...
-JL
SeaOS: Adding VT-x, networking, and ARM support
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
- Troy Martin
- Member
- Posts: 1686
- Joined: Fri Apr 18, 2008 4:40 pm
- Location: Langley, Vancouver, BC, Canada
- Contact:
Re: keyboard input
Try checking the buffer pointer on every keystroke to make sure an overflow won't happen. Then again, that's just my thought, probably not right!piranha wrote:...I must still work out is what to do when there is an overflow...
- piranha
- Member
- Posts: 1391
- Joined: Thu Dec 21, 2006 7:42 pm
- Location: Unknown. Momentum is pretty certain, however.
- Contact:
Re: keyboard input
It's not a problem of implementation, it's do I get rid of the new keystrokes, or the old ones?
-JL
-JL
SeaOS: Adding VT-x, networking, and ARM support
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
Re: keyboard input
You should discard the newest key strokes. If you remove the old ones characters will disappear from commands if you type ahead too much. Discarding new key strokes in this case will be easy to notice and easy to fix for the user.
clange
clange
- piranha
- Member
- Posts: 1391
- Joined: Thu Dec 21, 2006 7:42 pm
- Location: Unknown. Momentum is pretty certain, however.
- Contact:
Re: keyboard input
Yeah, thats what I was leaning towards.
I do have an overflow checker, but it's in the shell itself.
-JL
I do have an overflow checker, but it's in the shell itself.
-JL
SeaOS: Adding VT-x, networking, and ARM support
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
Re: keyboard input
overflow is not too bad if the buffer is circular
theres no way someone can type faster than than you can read the keys though
theres no way someone can type faster than than you can read the keys though