In the meanwhile I did some more fixes and improvements over the patch I posted on December 27th. Here is the complete ChangeLog:
- fix a crash that occurs when pressing a dead key in the monitor (I already reported this on December 8th, please drop that old patch) - keymap corrections - make ctrl+alt key combos work for the guest OS (e.g. ctrl-alt-delete) - don't pass undefined keycodes to the guest OS during KeyDown and KeyUp events (as it is already done for modifier key events) - make HOME, END, and DELETE keys work in the monitor - avoid compiler warnings - some code cleanup A bit more in detail: The file 'hw/adb.c' contains an array 'pc_to_adb_keycode[256]', which can be reversed and used as some kind of reference (have a look at the attached file 'adb_to_pc.txt'). You can see that this list is slightly different from the keymap in cocoa.m, which needs indeed three adjustments to have the same key codes in QEMU on an iMac like on a real PC (QZ_KP_ENTER was just a typo: 0x9c = 156, not 152). In the keymap, undefined keys are represented with the value 0, but they are forwarded to the guest OS without checking. Currently, when running Linux as guest OS, the kernel log is flooded with messages like atkbd.c: Unknown key pressed (translated set 2, code 0x0 on isa0060/serio0). atkbd.c: Use 'setkeycodes 00 <keycode>' to make it known. atkbd.c: Unknown key released (translated set 2, code 0x0 on isa0060/serio0). atkbd.c: Use 'setkeycodes 00 <keycode>' to make it known. when such an undefined key is pressed. 'setAppleMenu' was removed from the header in Mac OS 10.4, so we need to declare it ourselves to avoid compiler warnings when building on Tiger. In the function header of 'CustomApplicationMain', the types of argc and argv are not declared. This gives a warning with GCC4. We can safely remove these parameters since they are not used in the function (and are globally available in gArgc and gArgv anyway). Cleanups: - use bytes instead of dwords for keymap[] to save some space in the binary - properly warn about _all_ undefined keycodes (not only those that are beyond the bounds of keymap[]) - calling [NSApp nextEventMatchingMask: ... ] with 'nil' for 'untilDate:' has always been the same like using [NSDate distantPast], so we can save the space to initialize it - we don't need an array of 256 integers to remember the state of those few modifier keys: as they are all in the range 0x36-0x3E of ADB keycodes, we can use the lower 4 bits as an index into a bit field - "num lock" is handled by NSKeyDown and NSKeyUp anyway, and doesn't go through NSFlagsChanged, so we don't need to probe for it there It isn't that dramatically as the explanation maybe suggests (c: Just have a look at the patch. Excuse me for posting two versions of this patch. Fabrice, please apply this one. Sorry Jo.
cocoa_keyboard.diff.gz
Description: GNU Zip compressed data
reversed from pc_to_adb_keycode[] in qemu/hw/adb.c 0: 30 1: 31 2: 32 3: 33 4: 35 5: 34 6: 44 7: 45 8: 46 9: 47 10: 86 11: 48 12: 16 13: 17 14: 18 15: 19 16: 21 17: 20 18: 2 19: 3 20: 4 21: 5 22: 7 23: 6 24: 13 25: 10 26: 8 27: 12 28: 9 29: 11 30: 27 31: 24 32: 22 33: 26 34: 23 35: 25 36: 28 37: 38 38: 36 39: 40 40: 37 41: 39 42: 43 43: 51 44: 53 45: 49 46: 50 47: 52 48: 15 49: 57 50: 41 51: 14 52: 0 53: 1 54: 29 55: 219 56: 42 57: 58 58: 56 59: 203 60: 205 61: 208 62: 200 63: 0 64: 0 65: 83 66: 0 67: 55 68: 0 69: 78 70: 0 71: 69 72: 0 73: 0 74: 0 75: 181 76: 156 77: 0 78: 74 79: 0 80: 0 81: 92 82: 82 83: 79 84: 80 85: 81 86: 75 87: 76 88: 77 89: 71 90: 0 91: 72 92: 73 93: 133 94: 131 95: 245 96: 63 97: 64 98: 65 99: 61 100: 66 101: 67 102: 141 103: 87 104: 140 105: 170 106: 0 107: 70 108: 0 109: 68 110: 91 111: 88 112: 0 113: 0 114: 210 115: 199 116: 201 117: 211 118: 62 119: 207 120: 60 121: 209 122: 59 123: 54 124: 184 125: 157 126: 220 127: 222
_______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
