键盘体系.docVIP

鍵盤體系 author: sniff 從什麼開始說比較合理呀？就從硬體開始把：嚴格來說稱不上什麼鍵盤體系，但由於鍵盤的driver code比較的澀晦，所以就稱之為鍵盤體系了。 後注：什麼叫後注？也就是寫完後想說點什麼的意思呀！這篇文擋太長了（本來想寫的更長，真的，還有一些檔都沒有寫上去呀），大家還是用“文擋結構圖”來看把，厲害把，這麼多，全部手寫呀。 硬體相關 硬體，其實有一些內容，但我實在不想一段段的翻譯，大家想要的話，我把english文擋發給大家好了。 Keyboard Key  鍵盤代碼 鍵盤模式 鍵盤模式有4種， 在Linux 下你可以用kbd_mode -參數 來設置和顯示你的模式： 1） Scancode mode （raw ）raw模式：將鍵盤埠上讀出的掃描碼放入緩衝區 2） Keycode mode (mediumraw) mediumraw模式：將掃描碼過濾為鍵盤碼放入緩衝區 3） ASCII mode (XLATE ) XLATE模式：識別各種鍵盤碼的組合，轉換為TTY終端代碼放入緩衝區 4） UTF-8 MODE (UNICODE) Unicode 模式：UNICODE模式基本上與XLATE相同，只不過可以通過數位小鍵盤間接輸入UNICODE代碼。 鍵盤模組的上層漫遊： 鍵盤模組的最上層嚴格的說應該是TTY設備，這在以後描述。對於使用者而言，keyboard.c是我們的最上層。 在keyboard.c中，不涉及底層操作，也不涉及到任何體系結構，他主要負責：鍵盤初始化、鍵盤tasklet的掛入、按鍵盤後的處理、keymap的裝入、scancode的轉化、與TTY設備的通信。 Keyboard.c是一個大雜燴，包含了大多數keyboard的key的處理，因此代碼才變的龐大和複雜，我們可以修改它，讓他變的很小（但這樣做並不會使空間節省，因為keyboard.c的許多代碼是動態載入的）。 Keyboard.c中的int __init kbd_init(void) 函數是鍵盤代碼執行的開始點，但keyboard.c並非是一定執行的，你必須先定義CONFIG_VT（Character devices - Virtual terminal）才有效，為什麼？因為kbd_init（）是在tty_io.c 的 tty_init（）中被調用的。 ★Kbd_init（）在進行一些基本初始化後，執行kbd_init_hw（），此函數可以看做是一個統一的上層介面，對於不同的體系或相同體系下不同的board，他們的kbd_init_hw（）的實現代碼是不同的（同過CONFIG_XXX_XXX來實現），他的實現代碼就是操作硬體。 kbd_init_hw（）會：檢查硬體及有效性、分配資源和中斷、操作寄存器的實現函數調用。 初始化一完成，就把keyboard_tasklet放到CPU tasklet中（注意到keyboard_tasklet 是開放出來的，等下可以看到怎麼使用它）。 現在就等你按鍵了，當有按鍵時，會調用鍵盤中斷處理函數，一般都是體系下的keyboard_interrupt()，此函數會調用到keyboard.c中的handle_scancode() 。 ★handle_scancode()就是我們的重點，這個函數最終決定了我們按下的key如何處理，在下面會分析他的流程，他主要做：與TTY的通信、keymap的裝入、按鍵的處理。 handle_scancode()處理的結果就是把你按下的key發到不同的處理函數中，一般的，這些函數離最終的結果已經很近了。這其中，大多數的函數都會調用put_queue() 函數。 ★put_queue（）的工作原理就是利用TTY, 它將經過轉換的鍵盤功能碼用tty_insert_flip_char()放入到當前TTY的flip buffer中，然後將緩衝區輸出任務函數(flush_to_ldisc)添加到控制臺任務佇列(con_task_queue)並啟動控制臺軟中斷執行該任務函數. flush_to_ldisc()翻轉讀寫緩衝區,將緩衝區接收資料傳遞給tty終端規程的n_tty_receive_buf()接收函數,n_tty_receive_buf()處理輸入字元,將輸出字元緩衝在終端的迴圈緩衝區(read_buf)之中.用戶通過tty規程的read_chan()讀取read_buf中的字元.當多個進程同時讀取同一終端時, 使用tty-atomic_read信號燈來競爭讀取權. Kbd_init()開始點： int __init kbd_init(void) { int i; struct kbd_st