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.

Attachment: 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

Reply via email to