展訊平台訊息傳遞之鍵盤訊息

    工作已經馬上四個月了！該動動筆祭奠祭奠這些時光了~

    這兩天有個新案子，在以前的手機基礎上增加了三個側鍵，要做成音樂手機的上一曲，下一曲，暫停鍵。我的工作倒是很簡單，找幾個意思差不多的虛擬鍵盤對應到相應的檔案就OK了，但是上層是怎麼把訊息對應到正確的按鍵呢？

    在KEYPAD.C中有一個專為鍵盤而建立的進程KPDSVR，並規定了THREAD_ENTRY(KPDSVR)入口，在進程的初始化中，我們馬上看到了註冊進程以及進程的一些初始化，在初始化函數Init()中，除去常規的那些出錯處理，做的最主要的一件事就是HAL_RegCallback(TB_KPD_INT, KPDSVR_Callback);向核心註冊了一個CALLBACK函數KPDSVR_Callback，這個函數其實就是我們常見的中斷處理函數，通過某種機制，在有鍵盤按下會發生中斷（注意，我們現在用的是中斷而不是輪詢），中斷後就由這個函數只做了一件事，向上面發送一個訊息，告訴KPDSVR這個進程有哪個鍵盤，做了什麼動作（不知道這可不可以理解為中斷的上半部）。

    再往下看，竟然是個for(;;)，情何以堪，和UC差不多？在for裡面的第一句key_sig_ptr = (KPDSVR_SIG_T *)SCI_GetSignal(KPDSVR);原來中斷裡面的訊息在這裡被捕獲了，在迴圈一遍後如果沒有新的按鍵按下即訊息佇列中沒有新的訊息時，此進程掛起，等待中斷。

    然後，此進程做的事情也相當簡單，在例行的排錯後，判斷過power鍵，以及普通鍵是down還是up，又直接向上層發送了一個訊息，如SCI_SendEventToClient(KEYPAD_SERVICE, KPD_UP, (void *)key);內容包含進程ID，按鍵動作，鍵盤ID，這樣這一訊息就被核心發到MMI裡面去了，但是，至此，訊息傳遞的鍵盤ID還是我下面配的虛擬鍵盤ID。

    通過打一些LOG顯示，發現在MMK_MSG.C中的MMK_DispatchExtSig函數吸收了下面傳上來的這些訊息（其實肯定是核心吸收然後調用這個函數處理這些訊息的），這個函數是各處理序間通訊訊息處理的總匯，首先就要判斷是哪個進程發送過來的訊息，這裡只考慮KPDSVR進程，處理過程也是相當簡單，一句話，彙集後再分散，調用MMK_DispatchMSGKbd( (*signal_ptr) );引用原文注釋dispatch the key message
after translate the signal of RTOS to MMI Message，在這個處理函數中就有了鍵盤值的轉化函數MMIDEFAULT_ConvertKeyCode，將我們的虛擬鍵盤值，通過一個static const表，轉化成為上層中固定的鍵盤值，這樣，在MMI層引用的判斷某鍵盤按下、彈起通過一系列的訊息的傳遞終於找到了實際的物理鍵盤！

 

PS：當然，訊息傳遞到這遠遠沒有傳遞到MMI的使用者層，但是它已經完成了從驅動到應用的鍵盤轉換。至於圖形介面中捕獲的訊息 case MSG_CTL_CANCEL: case MSG_APP_OK:此類訊息怎麼傳上來的。。。。。