keyboard input

[Creature]

I believe a buffer is a good idea (although it is still a buffer which will never be able to grow bigger and if there is only need for i.e. 10 chars, a buffer of 255 chars would waste about 245 chars of memory space). If you have some kind of dynamic memory allocation, like the new and delete operators in C++, you could implement some sort of simple vector which resizes the buffer as more or less space is needed.

[Troy Martin]

That's why a good keyboard function should be similar to fgets():

Code: Select all

char *fgets(char *str,int num,FILE *stream);

That way you specify how long the buffer is minus 1, since you always need 1 byte for the null.

[yemista]

Ok, but how do you know where to put the keystrokes? What would a keyboard driver do? Im comfortable setting up the interrupt and converting the scancodes and all that, but once you have that, how do you know where to put it? Maybe I shouldnt even think of this at this point?

[dosfan]

My keyboard interrupt translates the scancodes and stuffs the result into a circular ring buffer 255 bytes long. A process will open the terminal and start reading at the ring buffers 'read position'.

how do you know where to put it?

You buffer a limited amount (circular buffer works nicely) until somebody asks for it?

[Masterkiller]

I understand that you are trying to make a device driver for keyboard but you don't know what to do with received data. You could look what other OS-es like windows do. Windows has only one window at a time with keyboard focus, that reacts to keyboard. The keyboard interrupts write keyboard data in special window buffer called "key input" which has a limit of 100 bytes (if not changed from the registry). Perhaps that is good idea. If you system is multi-threated and has standart process and thread, keep in special kernel memory the ID of the thread and the process that should receive keyboard event and data. On interrupt read current focused task and signal it for keyboard event. The event handle code in the process itself should receive keyboard data if has some and then what to do with that data is handled by application programmer.

[yemista]

Ok that makes alota sense, but let me elaborate a bit on what I was thinking of doing. I might be getting head of myself, but these past few days Ive been thinking of a way to have a uniform driver interface, so each driver would be a structure with read/write functions, optional init function, id number, and a data buffer. Im starting to see this wont really work and everything needs to be handled seperately, but I still need a way to echo keyboard characters to the screen. My original idea was to have the keyboard ISR put the data in the keyboard drivers buffer, and also copy it to the graphics drivers buffer, and that would take care of refreshing the screen. Im not going to do that anymore, but if I want echo to work do I just go ahead and do what you said with storing the data in a buffer and also make sure to write it to video memory?

[Creature]

I'll show you what I do when I handle keyboard input; I firstly have a GetChar function which plainly converts a scancode to a character (from a keyboard scancode table). I also have a keyboard handler (IRQ1 handler) that puts the char it reads from the GetChar function onto the screen. Both of these functions don't store input in any way. I have 2 interrupt handlers for IRQ1, one is stored in an array of function pointers (like in JamesM's tutorials) whilst the other one just plainly gets called by the IRQ handler (this other one is the one I mentioned in my second sentence ). Secondly I have a custom interpretation of the 'cin' object from C++ named 'cread'. As soon as I call something like this

Code: Select all

string some_string;
cread >> some_string; //Where I also have a vector-inheriting class called string ;-)

The operator>> of cread will enable a boolean (volatile boolean). As soon as the keyboard (IRQ1) handler gets called, it checks if this boolean is enabled. If it is, it puts a character in the vector (or removes a character on backspace) and draws a new character onto the screen, if it isn't, it just does what it always does and puts a character on the screen. If you don't have dynamic memory allocation, a static buffer could be used as mentioned before. The operator>> waits for the keyboard handler to set a boolean called 'HasInputSomething' to true. The operator>> enters a loop waiting for that boolean to become true. For example.

Code: Select all

while(!HasInputSomething);

This boolean will only become true as soon as the user presses the return/enter key. After this, the operator>> just reads the characters inside the vector and puts them into a string (and clear the vector if necessary).

And this way the caller now has what the user input in his/her string. Note that my operator>> of cread will wait infinitely for the user to press return (just like in C++ with cin) and cin only collects input until it reaches the first space character (I believe tab and a newline also count).

Hopefully this was of some help.
Creature

[yemista]

That is an interseting idea. So you just ignore the keyboard input unless someone is looking for it?

[Creature]

That is an interseting idea. So you just ignore the keyboard input unless someone is looking for it?

Yes. The characters are displayed on the screen by a PrintChar function or a custom implementation of cout or whatever you like, but they aren't actually saved by anything. I only start saving them as soon as my input-collecting function is called (operator>> of cread). You could do the same in C, except you wouldn't be able to use operator overloading and would have to use a static buffer (or maybe something dynamic using malloc and free).

[yemista]

I never thought of it that way. I think I was looking at the problem a bit wrong. Thank you for your help