Keyboard driver

[oboy]

I'm going to write a keyboard driver to my microkernel, but I have a question.
Is this the best way:
When a program wants user input from the keyboard, it tells the keyboard driver process to create a buffer for it and then when the keyboard IRQ fires, the keyboard handler handles it and pushes the scancode on the buffer and then tells the owner of that buffer that it has received data.

How and where should I translate scancodes to real symbols? In the keyboard driver, instead of pushing just the scancode, it pushes both the scancode and the translated symbol?
Or should the keyboard driver just push the scancode and then libc translates using the specified keymap, loaded into the program's user space?

Should I have different attributes for buffers? Like, tell the owner process just when key X is hit instead of any key?
How should I specify that key when the keyboard driver doesn't know about any keymaps?

How should I handle meta keys like alt and shift?

I hope for some input now

[Pype.Clicker]

imvho, the user program should never be required to translate scancodes itself. That will completely kill any kind of portability.

[AR]

I would probably (From a design point only, you'll have to determine if it's practical) simply have the keyboard driver send the scancode as a message to the input service, the input service translates the scan code(s) and forwards it to the GUI server which can forward it to the active window, the latency will be pretty bad with this approach but it has a clean structure. Of course the obvious simplification is to combine the GUI and Input servers into the same process which should give quite good performance with the "favour what the user is currently doing" logic.

The obvious advantage is that you're leveraging the (hopefully) heavily optimized message queues as buffers simplifying the driver and server logic (no internal buffers are needed, simply process and send)

[Pype.Clicker]

yep. Merging input & gui server (or consoles servers if you have no gui. that doesn't really matters) aswell i suggest ...

[oboy]

OK, merging input service with GUI/Console-service sounds good.
How is a console service often designed?
Like this?
1. Program starts, sends message to input service
2. Input service creates buffers and everything needed for a console
3. Input service iterates through a list of input drivers selected (keyboard, mouse etc) and sends a message to each one
4. An input driver receives the message and creates buffers etc needed by the driver, returns a handle to the input service.
5. Input services stores all handles in the data for the console and returns a handle for the console to the program
6. stdin and stdout are mapped to that handle

[Brendan]

Hi,

OK, merging input service with GUI/Console-service sounds good.
How is a console service often designed?
Like this?
1. Program starts, sends message to input service
2. Input service creates buffers and everything needed for a console
3. Input service iterates through a list of input drivers selected (keyboard, mouse etc) and sends a message to each one
4. An input driver receives the message and creates buffers etc needed by the driver, returns a handle to the input service.
5. Input services stores all handles in the data for the console and returns a handle for the console to the program
6. stdin and stdout are mapped to that handle

Everyone does things differently, but here's my method:

1. Program starts and creates a "client connection" to the User Interface (the GUI/Console-service), which uses a defined protocol for all user related things (video, sound, mouse, keyboard, etc) via. messaging/IPC.

2. The input service (and all other user related device drivers) also create a connection to the User Interface, which uses a "device specific" protocol via. messaging/IPC.

3. The input driver sends "packets" of data to the User Interface - for keyboards this consists of an 8 bit keycode, a 32 bit unicode character and a set of state flags (capslock state, numlock state, scrolllock state, control key states, shift key states, alt key states).

4. When the User Interface receives data from an input driver it checks for global actions (control+alt+delete, control+tab, control+shift+tab, etc), and handles them.

5. If it wasn't a global action, then the User Interface sends the keypress data to an optional "keypress processor", which is a utility that handles keyboard macros and "Input Method Editors" (see notes below). After processing this utility sends the modified keypress data back to the User Interface.

6. The User Interface ends up sending the data to the currently active client connection (application, window, screen or whatever) via. messaging/IPC.

For some languages (Japanese, Korean, Chinese, etc) where there's thousands of symbols/characters (one for each word), the keyboard is used to enter parts of a word and the Input Method Editor allows the user to select a word (or a symbol/character) that begins with the parts of the world entered. For example (in English), the user would press 'c' then 'a', the IME would present a list of words that start with 'ca' (cat, car, camera, etc), the user would select the word they want (camera), and then the IME would send the selected word/symbol/character to the User Interface.

For a better description, see http://www.answers.com/topic/input-method-editor.

I use the same thing for keyboard macros, which allows the user to assign a sequence of keypresses to a specific key. For example, you could define "alt+N" to be your email address so that instead of typing it out every time you just press the shortcut key, or "alt+w" might start a web browser.


Cheers,

Brendan

[Mahretz]

Hi everyone ...

I know it`s probably not the place for it ..but I`m starting to develop my own OS ...and I`m egyptian ..so was tryin to make the OS read and write in arabic beside english ...

I`d really appreciate it ...if someone told me what should be done .....I only have my boot loader jumping to my kernel ..which loops ...I implemented some c functions as well ...( i.e. printf , scanf , etc... )

thank u in advance ....

bbye

[AR]

x86 based computers are hardwired as natively English, to support any (complex) languages other than Latin based (eg. English, German) you will most likely have to use Fonts, Unicode [preferably for compatibility (you can use other encodings though)] and VESA [or at least a graphical VGA mode]. Essentially you'll have to draw each character to the screen manually in a graphical mode, this makes it difficult to use anything but Latin-based languages at the lowest levels (Kernel boot procedure, bootloader).

[Pype.Clicker]

OK, merging input service with GUI/Console-service sounds good.
How is a console service often designed?

Well, i'd say that the console service (which only make sense if you have no GUI service) will have a collection of "console information" and a single "activated" console. When receiving bytes, it will push them on the activated console's "stream".

I'm not sure it makes much sense to send messages between the console and the app. The application is likely to want its input look like a file regardless of where it actually comes from. Among other things, the user is likely to want to edit its input (you know, typos and things alike), so i'd suggest the data remain on the console service until the user hit "ENTER" where the whole line is send along the stream to the application.

Sending "function" and "control" keys, however, could nicely fit a message (and therefore will somehow appear as "out of band" data). Probably a game could like to tell the console service "makes all my input message-based and delivered immediately (e.g. sort of "raw input")

I have some additionnal clues about console rendering on my wiki if you like.


@Mahretz: we had a talk about non-latin language a couple of weeks ago. If you dig the forum, you should be able to find it back.

[Mahretz]

Thank you guys for ur quick replies ...and well .....guess I have to dig more in the forum ...don`t mind the dust though ...

Thanks again ...and bye