Openmoko Bug #1533: The keypad shows brackets number in dialer screen and creat new message

Openmoko Public Trac bugs at
Wed Aug 6 09:14:50 CEST 2008

#1533: The keypad shows brackets number in dialer screen and creat new message
 Reporter:  wendy_hung       |        Owner:  zecke  
     Type:  defect           |       Status:  closed 
 Priority:  highest          |    Milestone:  ASU    
Component:  System Software  |      Version:  GTA02v5
 Severity:  blocker          |   Resolution:  fixed  
 Keywords:  keypad           |     Blocking:         
Blockedby:                   |  
Changes (by zecke):

  * status:  reopened => closed
  * resolution:  => fixed


 Your installed Xglamo version does _not_ contain the fix for the bracket
 handling. I don't know why this is the case but if you upgrade it it
 should work for you as well. Closing the bug due this again. Feel free to
 reopen if the upgrade doesn't fix the bug.

 Also I'm interested how you ended up with Xfbdev running and Xglamo not
 being installed? Which image did you build?

 Your glamo version:
 commit d1ab8c0ec48821ef866e927c52b47587a0affc56
 Author: Holger Hans Peter Freyther <zecke at>
 Date:   Wed Jun 25 10:41:29 2008 +0200

     [keyboard] Use the proper source for the high keyboard. fix bugs
         I saved the input for the high keycodes to high_keys but to
         the keycode I went back to use b[1] and b[2] and this happened to
         most of the time. Fix the bug and use high_keys.

 You want to have at least:
 commit aa7488dd64a716e7c3efae672bb74130205b4eb4
 Author: Holger Hans Peter Freyther <zecke at>
 Date:   Wed Jul 23 20:04:12 2008 +0200

     [keyboard] Do not send keycodes >= NR_KEYS to kdrive as they are not

         NR_KEYS as of linux/keyboard.h is 256. That fits into unsigned
 char, the
         linux_to_x_keymap is of that size, KdEnqueueKeyboardEvent takes
         char that will happily take up to 256 different values. Now with
 the linux
         input framework we can report high keys. KEY_POWER2 (365) is such
 a high
         keycode, we get this properly reported through extended keycode's
 but the
         rest of kdrive fails to handle this. So these 365 get casted to
         char (365&0xff) and then something will happen...

         In the Openmoko case we managed to hit a modifier that changed our

         Do not report keys to kdrive that it currently can not properly


Ticket URL: <> <>
openmoko trac

More information about the buglog mailing list