> You are wrong, really. > In fact the first step the scan-codes->keycodes convertion is done in > the server itself. The server sends to an application keycodes and xlib > converts them into keysyms (does the second step only). > The second convertion is very flexible because Xlib gets all needed data > from external tables usually called 'a keboard map'. Note all these maps > contain only keycode->keysym matches. > But tables for scan-code->keycode convertion are builtin into the server > code.
I thought I was wrong, actually. I'd thought that the whole point of X's client/server was to separate the hardware specific things (like keyboard scancodes). Thanks for your explaination. > Regarding your case... > A usual PC keyboard produces two kind of scan codes. Some keys emit > simple one-byte codes but there are keys that produce two-byte sequences > (extended scancodes). Most of keyboard drivers (including a 'system' Linux > driver and an Xserver's one) convert two byte sequences into a one byte > code. Unfortunately, different drivers do it in own way. I knew that some keys generated extended keyboard scancodes, but I didn't realize that they get converted into single-byte "driver scancodes." > The Left key you mentioned emits a sequence that the Xserver's driver > converts to keycode 100. But if some other key produces such one-byte code > (or rather the one-byte code which is converted to 100 by the Xserver > driver) an application will get the same keycode from both keys. Aha. I see the problem. > I don't know what scan-codes your iBook keybord produces. But I think > a some part of Linux code converts them trying emulate PC keyboard codes. The linux-ppc kernel has an option (CONFIG_MAC_ADBKEYCODES) to use the "old" ADB-style keycodes. I imagine setting this option to "no" uses the conversion you're talking about. For the record, the scancodes I see (from showkey -s) are as follows: KeyPad Equals : 0x5c 0xdc Left Arrow : 0xe0 0x4b 0xe0 0xcb I get these same keycodes from the iBook's built-in keyboard and an external Apple USB keyboard. What's interesting is that I get the exact same keycodes on the Apple USB keyboard when it's hooked up to a regular PC. I think the problem is that KP-Equals is not a normal key on PC keyboards, so people don't often see it. > On of solutions could be to change a source code of Xserver's keyboard > driver or a code of Linux driver which emulates PC scan-codes. For the source-fix option, I think that the change should be in the Xserver, because it's not a problem in the PPC-specific keycode conversion. In the Xserver source, where are these keycodes generated? I think it's in xc/programs/Xserver/hw/xfree86/os-support/linux/ but I can't really tell which file. > But there is another way. There always is. :) Are these medium-raw codes the ones shown with showkey -m? If so, under X I get different results if I start with CustomKeycodes on or off as I do on the console: Custom on + KP-Equals : uõ ( 0x75 0xf5 ) Custom on + Left Arrow : ié ( 0x69 0xe9 ) Custom off + KP-Equals : ( 0x0d 0x8d ) - notice no char Custom on + Left Arrow : àKàË ( 0xe0 0x4b 0xe0 0xcb ) Console + KP-Equals : = ( 0x3d ) Console + Left Arrow : [D ( 0x1b 0x5b 0x44 ) > The thing is the system driver has at least > three levels (I mean a usual PC keyboard driver and don't consider mac->PC > codes conversion). The first one just gets scan-code from hardware and can > give such 'raw codes' to any interested application. The second one is > that which converts raw scan-codes to some intermediate one-byte codes. > Such 'middle raw' codes also can be taken by an application. And the third > level converts these 'keycodes' into symbols according to a keyboard map. > > Note that the console drivers second level generates different keycodes > for your two keys. I think what you mean here is that the console drivers' third level generates different keycodes, because I see different charcters on the console when I type (i.e. in bash). Though the showkey -m also shows different results from showkey -k. > Xserver's driver normally gets codes from the first level of the system > driver (i.e. raw scan-codes). But it's possible to make them get 'middle > raw' one-byte codes. In this case the codes of two keys you are talking > about will be different. But on the other hand in such case many of > keycodes can become 'shifted' and you will need to make a new keyboard map. > > To switch Xservers driver to getting 'middle raw' codes add into > XF86Config (keyboard section) the option > Option "CustomKeycodes" "on" Ah. I wondered if X would be able to use the console keycodes. The answer seems to be 'yes.' What's interesting is that in X with the medium-raw codes enabled, most of the keys still work fine (a-z, 1-0, tab, keypad = even). However some of the 'strange' keys aren't mapped properly. Namely all the arrow keys and the right alt... things like that. But it should be possible to change that, it seems. But it'll take some time. I'd appriciate it if you could tell me in which (set of) files these raw scancodes are converted to XFree scancodes. Thanks for your explainations here. The fixed some of my assumptions and will help me to track this down. Frank _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
