From: Benjamin R. <Ben...@ep...> - 2003-08-12 11:02:54
|
Hi Yan, Thanks for all the help and those details. It completes the picture nicely, even when it gets confusing sometimes ;-). Yan Wong <yan...@ne...> writes: > "Function" (bottom right key: used as a modifier to access the > function keys on a laptop) > KeyCode=<0x20000> Unicode=<> KeySym=<??> detail=?? sendevent=-1 > type=2 I guess we can just ignore this one, as long as all the combinations that it creates turn out correct. > "Alt" (also known as "option" to mac users) > KeyCode=<0x800> Unicode=<> KeySym=<Meta_L> detail=?? sendevent=-1 type=2 > > "Command" (aka apple/prezel) > KeyCode=<0x100> Unicode=<> KeySym=<Alt_L> detail=?? sendevent=-1 type=3 > > F11 > KeyCode=<0x670010> Unicode=<> KeySym=<L1> detail=?? sendevent=0 type=2 > > F12 > KeyCode=<0x6F0010> Unicode=<> KeySym=<L2> detail=?? sendevent=0 > type=3 These are the same here on a regular keyboard. The Alt and Command associations are probably intended this way, it would be a bad idea to change them now. The L1/L2 thing comes because of duplicate assignments in the X11 headers, where these strings originate. Note that you still can bind to "F11" and "F12", even though the primary names of the keys are "L1" and "L2". As "L1" and "L2" are pretty unusual IMO, we could probably fix this. > Num Lock > KeyCode=<0x10000> Unicode=<> KeySym=<??> detail=?? sendevent=-1 > type=2 If that is really all that you get here, we can't help it and we just have to treat it the same as the "Function" key above, at least for now. The keycode 0x01 is a regular keycode, usually used for the "S" key, so we just have to ignore it and use the translation that the OS gives us, i.e. none in this case. > The numeric keypad numbers and */=-+. do as you might expect > (i.e. are interpreted by tcl as the "normal" versions, even though > they have different key codes. Yes. I had already included those in my previous patch. > The clear key (on the numeric keypad) is just plain weird. Here is > the full output of what I get with your script: > > ############### <KeyPress>: KeyCode=<0x47001B> Unicode=<> > KeySym=<Clear> detail=?? sendevent=0 type=2 > ############### <KeyPress>: KeyCode=<0x0> Unicode=<> KeySym=<??> > detail=?? sendevent=-1 type=2 > ############### <KeyRelease>: KeyCode=<0x47001B> Unicode=<> > KeySym=<Clear> detail=?? sendevent=0 type=3 > > Note the absence of key release of the <0x0> key. That is nearly the same that I get. Just that the middle KeyPress is with keycode 0x10000, like what you got for NumLock. > [About Tk on Linux] I was running wish using the X11 server on the > mac. The Enter key which gives the normal KeyCode on the mac also > gives the KP_Enter KeySym when interfacing to tcl/tk on linux via > the X11 client. Using the "strange" enter key gives: > > ############### <KeyRelease>: KeyCode=<0x3C> Unicode=<^C> > KeySym=<U0003> detail=?? sendevent=0 type=3 Looks like a problem in Apple's X11 port to me. You may want to repeat the experiment with xev and post a bug report to Apple. It's basically the same problem as the one with the missing keysym in Tk, the X11 keyboard mapping doesn't know what to do about that strange keycode (0x3C == 0x34 + 8). Who knows, maybe if and when you get an answer from Apple, it will tell us something about what that keycode is *supposed* to mean and/or why it isn't documented. benny PS: The mailing list archives seem to be working again. |