iBook us-keyboard problem
I have an iBook with a US keyboard layout, and I'm having a wierd problem I hope you can help with. The mac keyboards have a "keypad equals" key. X doesn't support that as separate from regular equals, but I'd like to use it to type equals. The problem is that both this KP-equals and the left-arrow key have the same keysyms. If I try to modify one, I modify both. Here's the relevent xev output: KeyPress event, serial 27, synthetic NO, window 0x201, root 0x48, subw 0x0, time 35558015, (180,101), root:(183,519), state 0x0, keycode 100 (keysym 0xff51, Left), same_screen YES, XLookupString gives 0 characters: "" KeyRelease event, serial 27, synthetic NO, window 0x201, root 0x48, subw 0x0, time 35558135, (180,101), root:(183,519), state 0x0, keycode 100 (keysym 0xff51, Left), same_screen YES, XLookupString gives 0 characters: "" KeyPress event, serial 27, synthetic NO, window 0x201, root 0x48, subw 0x0, time 35560194, (180,101), root:(183,519), state 0x0, keycode 100 (keysym 0xff51, Left), same_screen YES, XLookupString gives 0 characters: "" I am actually hitting different keys here, but it doesn't look like it. What is wierd is that these keys generate different keysyms and characters on the console. I type an '=' with both keys (on Debian sid). I had a suggestion to look in the XF86 keyboard code. Does anyone here have an idea of which files to start to look in? Will this be a C-code problem or a configuration issue somewhere? Or does anyone know how to see the scancodes that X thinks I have? Here's the version info from the top of the XFree86.0.log: XFree86 Version 4.3.0 (DRI mach64-0-0-6-branch) Release Date: 27 February 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.20-ben8-xfs-lolat ppc [ELF] I'm using the Xserver packages that Michael Däzner provides. Do you need any other info? Thanks for any help, Frank ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: iBook us-keyboard problem
OK, after some more resarch, I have some idea of what's going on. It seems that the X server gets the scan codes from the kernel, then passes these scan codes to the X client. xlib has some nice functions to then convert these scan codes into keycodes, then into keysyms. (Correct me if I'm wrong here.) So, I looked into xc/lib/X11/XKeysymDB, which seems to have the kind of information I want, but not the actual scan codes I'm looking for. Then I looked at xc/include/keysymdef.h, which seemed to be a better place. But after looking at these, they both seem to be keysym definitions, not scan code (or even key code) definitions. Where are the scan codes defined, or mapped or whatever? Thanks for any pointers? Frank On Wednesday 04 June 2003 09:52, Frank Murphy wrote: > I have an iBook with a US keyboard layout, and I'm having a wierd problem I > hope you can help with. > > The mac keyboards have a "keypad equals" key. X doesn't support that as > separate from regular equals, but I'd like to use it to type equals. The > problem is that both this KP-equals and the left-arrow key have the same > keysyms. If I try to modify one, I modify both. > > Here's the relevent xev output: > > KeyPress event, serial 27, synthetic NO, window 0x201, > root 0x48, subw 0x0, time 35558015, (180,101), root:(183,519), > state 0x0, keycode 100 (keysym 0xff51, Left), same_screen YES, > XLookupString gives 0 characters: "" > > KeyRelease event, serial 27, synthetic NO, window 0x201, > root 0x48, subw 0x0, time 35558135, (180,101), root:(183,519), > state 0x0, keycode 100 (keysym 0xff51, Left), same_screen YES, > XLookupString gives 0 characters: "" > > KeyPress event, serial 27, synthetic NO, window 0x201, > root 0x48, subw 0x0, time 35560194, (180,101), root:(183,519), > state 0x0, keycode 100 (keysym 0xff51, Left), same_screen YES, > XLookupString gives 0 characters: "" > > I am actually hitting different keys here, but it doesn't look like it. > > What is wierd is that these keys generate different keysyms and characters > on the console. I type an '=' with both keys (on Debian sid). > > I had a suggestion to look in the XF86 keyboard code. Does anyone here have > an idea of which files to start to look in? Will this be a C-code problem > or a configuration issue somewhere? Or does anyone know how to see the > scancodes that X thinks I have? > > Here's the version info from the top of the XFree86.0.log: > > XFree86 Version 4.3.0 (DRI mach64-0-0-6-branch) > Release Date: 27 February 2003 > X Protocol Version 11, Revision 0, Release 6.6 > Build Operating System: Linux 2.4.20-ben8-xfs-lolat ppc [ELF] > > I'm using the Xserver packages that Michael Däzner provides. Do you need > any other info? > > Thanks for any help, > > Frank > > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: iBook us-keyboard problem
I was trying to find this info a while ago, too. When I replaced the Solaris Xsun Xserver with XFree86, an xmodmap in our system that used keycodes was no longer working. The problem was that XFree86 was translating the scancodes into different keycodes than Xsun was. This happened with both the openwindows (Solaris) and XFree86 versions of xmodmap, and also using the openwindows xlib. So I concluded that the scancode to keycode translation must be happening in the keyboard driver used by XFree86. I never found the source of this - I fixed my problem by changing the xmodmap to use the more portable keysyms, rather than keycodes. I'm guessing that the XFree86 keybaord driver lives in xc/programs/Xserver/hw/xfree86/input/keyboard. After a quick look in here and the files that it includes, I couldn't find what you are looking for, but it might be a place to start, if you haven't already looked at this. Regards, Lindsay Haigh Frank Murphy cc: Sent by:Subject: Re: iBook us-keyboard problem [EMAIL PROTECTED] 86.Org 06/06/03 07:13 Please respond to devel OK, after some more resarch, I have some idea of what's going on. It seems that the X server gets the scan codes from the kernel, then passes these scan codes to the X client. xlib has some nice functions to then convert these scan codes into keycodes, then into keysyms. (Correct me if I'm wrong here.) So, I looked into xc/lib/X11/XKeysymDB, which seems to have the kind of information I want, but not the actual scan codes I'm looking for. Then I looked at xc/include/keysymdef.h, which seemed to be a better place. But after looking at these, they both seem to be keysym definitions, not scan code (or even key code) definitions. Where are the scan codes defined, or mapped or whatever? Thanks for any pointers? Frank On Wednesday 04 June 2003 09:52, Frank Murphy wrote: > I have an iBook with a US keyboard layout, and I'm having a wierd problem I > hope you can help with. > > The mac keyboards have a "keypad equals" key. X doesn't support that as > separate from regular equals, but I'd like to use it to type equals. The > problem is that both this KP-equals and the left-arrow key have the same > keysyms. If I try to modify one, I modify both. > > Here's the relevent xev output: > > KeyPress event, serial 27, synthetic NO, window 0x201, > root 0x48, subw 0x0, time 35558015, (180,101), root:(183,519), > state 0x0, keycode 100 (keysym 0xff51, Left), same_screen YES, > XLookupString gives 0 characters: "" > > KeyRelease event, serial 27, synthetic NO, window 0x201, > root 0x48, subw 0x0, time 35558135, (180,101), root:(183,519), > state 0x0, keycode 100 (keysym 0xff51, Left), same_screen YES, > XLookupString gives 0 characters: "" > > KeyPress event, serial 27, synthetic NO, window 0x201, > root 0x48, subw 0x0, time 35560194, (180,101), root:(183,519), > state 0x0, keycode 100 (keysym 0xff51, Left), same_screen YES, > XLookupString gives 0 characters: "" > > I am actually hitting different keys here, but it doesn't look like it. > > What is wierd is that these k
Re: iBook us-keyboard problem
Hi, > OK, after some more resarch, I have some idea of what's going on. It seems > that the X server gets the scan codes from the kernel, then passes these scan > codes to the X client. xlib has some nice functions to then convert these > scan codes into keycodes, then into keysyms. (Correct me if I'm wrong here.) 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. 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. 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. 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. Thus this part of driver generates usual two-byte sequence for the Left key and some one byte code for your extra key. The problem is that the second part of system driver which gets scan-codes and converts them to one byte generates for Left key a code differnt from the 'equals' key code. Therefore console application can distinquish them. But the Xservers driver, as I said, do it in own way and its keycodes for these two keys are the same. 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. But there is another way. 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. 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" -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: iBook us-keyboard problem
>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 rig
Re: iBook us-keyboard problem
Hi, > 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 Wow! It is exactly what I told about. I didn't say what Xserver's driver does with one-byte codes. Actually it does: - converts 0xe0 sequences to some one byte code - and then adds 8 to every code, including one-byte scan-codes and codes (one-byte too) got from the sequences covertion. Therefore 0x5c code after that becomes 5c+8 = 0x64 hex or 100 dec. And the Left arrow sequence at the first step is converted to 0x5c too and after adding 8 becomes 100 (dec). > 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. No. Since the server's driver deals with hardware scan-codes, this part isn't a Linux-specific. See xc/programs/Xserver/hw/xfree86/common/xf86Events.c xf86PostKbdEvent(unsigned key) procedure. > There always is. :) Are these medium-raw codes the ones shown with showkey -m? Hmm. I have not a Linux box here but and I searched 'man showkey' in Internet. If I understand it right, showkey -k (or --keycodes) shows medium-raw codes. > > 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. I meant "since you see different characters (codes from the third level) for these two keys, it means the keys medium-raw codes (codes from the second level) are different too". :) > 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. Yes it's what I meant saying 'shifted'. A main (and maybe only one) difference between 'raw' and 'medium-raw' codes is that 'extended scan-codes' are replaced with one-byte codes. Thus all keys that produce 'ordinar scan-codes' have the same value of 'raw' and 'medium-raw' codes. Only keys that generate 'extended scan-codes' have differnt values. Take any documentation about PC keyboard scan-codes and you will see all that 'strange' keys are those which produce extended scan-codes. > I'd appriciate it if you could tell me in which (set of) files these raw > scancodes are converted to XFree scancodes. I already mentioned that function: xf86PostKbdEvent(unsigned key) in Xserver/hw/xfree86/common/xf86Events.c -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: iBook us-keyboard problem
On Sat, Jun 07, 2003 at 07:51:04PM +0700, Ivan Pascal wrote:
> Hi,
>
>> 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
>
>Wow! It is exactly what I told about.
>I didn't say what Xserver's driver does with one-byte codes.
>Actually it does:
>- converts 0xe0 sequences to some one byte code
>- and then adds 8 to every code, including one-byte scan-codes and codes
>(one-byte too) got from the sequences covertion.
>
> Therefore 0x5c code after that becomes 5c+8 = 0x64 hex or 100 dec.
>And the Left arrow sequence at the first step is converted to 0x5c too and
>after adding 8 becomes 100 (dec).
The X server's driver uses codes (like 0x5c) that it doesn't expect to
ever see as input to encode the 0xe0 0xXX two-byte codes.
We have a KEY_KP_Equal value defined in common/atKeynames.h: 0x76 (+8 = 126).
This conflicts with the value used for in xkbcomp/keycodes/xfree86.
My suggestion would be the following patch for the XFree86 DDX, and
assign to a different value, assign to 126 in
xkbcomp/keycodes/xfree86, (and make to a keysym in the appropriate
places).
Index: xc/programs/Xserver/hw/xfree86/common/xf86Events.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/common/xf86Events.c,v
retrieving revision 3.149
diff -u -r3.149 xf86Events.c
--- xc/programs/Xserver/hw/xfree86/common/xf86Events.c 3 Apr 2003 16:20:23 -
3.149
+++ xc/programs/Xserver/hw/xfree86/common/xf86Events.c 9 Jun 2003 19:23:10 -
@@ -456,8 +456,14 @@
case 0x72:scanCode = KEY_AltLang; break; /* AltLang(right) */
case 0x73:scanCode = KEY_RCtrl;break; /* not needed */
}
+ } else
+#else /* i386 && SVR4 */
+ {
+switch (scanCode) {
+case 0x5C:scanCode = KEY_KP_Equal; break; /* Keypad Equal */
+}
}
-#endif /* i386 && SVR4 */
+#endif /* !(i386 && SVR4) */
#ifdef __linux__
if (xf86Info.kbdCustomKeycodes) {
Index: xc/programs/xkbcomp/keycodes/xfree86
===
RCS file: /home/x-cvs/xc/programs/xkbcomp/keycodes/xfree86,v
retrieving revision 3.20
diff -u -r3.20 xfree86
--- xc/programs/xkbcomp/keycodes/xfree8615 May 2003 13:31:58 - 3.20
+++ xc/programs/xkbcomp/keycodes/xfree869 Jun 2003 19:26:13 -
@@ -138,6 +138,7 @@
= 90;
= 91;
+ = 126;
= 118;
= 119;
@@ -298,7 +299,7 @@
=93; //
= 124; //
= 125; //
- = 126; //
+ = 156; //
= 127; //
= 128; //
Index: xc/programs/xkbcomp/symbols/us
===
RCS file: /home/x-cvs/xc/programs/xkbcomp/symbols/us,v
retrieving revision 3.12
diff -u -r3.12 us
--- xc/programs/xkbcomp/symbols/us 20 Nov 2002 04:49:03 - 3.12
+++ xc/programs/xkbcomp/symbols/us 9 Jun 2003 19:29:21 -
@@ -160,6 +160,7 @@
key { [ KP_Down, KP_2] };
key { [ KP_Next, KP_3] };
key { [ KP_Enter] };
+key { [ KP_Equal] };
key { [ KP_Insert, KP_0] };
key { [ KP_Delete,KP_Decimal ]};
Index: xc/programs/xkbcomp/symbols/pc/pc
===
RCS file: /home/x-cvs/xc/programs/xkbcomp/symbols/pc/pc,v
retrieving revision 1.8
diff -u -r1.8 pc
--- xc/programs/xkbcomp/symbols/pc/pc 15 May 2003 13:32:00 - 1.8
+++ xc/programs/xkbcomp/symbols/pc/pc 9 Jun 2003 19:28:53 -
@@ -165,6 +165,7 @@
key { [ KP_Down, KP_2] };
key { [ KP_Next, KP_3] };
key { [ KP_Enter] };
+key { [ KP_Equal] };
key { [ KP_Insert, KP_0] };
key { [ KP_Delete, KP_Decimal ]};
David
--
David Dawes
Founder/committer/developer The XFree86 Project
www.XFree86.org/~dawes
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: iBook us-keyboard problem
On Mon, Jun 09, 2003 at 03:31:01PM -0400, David Dawes wrote:
>On Sat, Jun 07, 2003 at 07:51:04PM +0700, Ivan Pascal wrote:
>> Hi,
>>
>>> 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
>>
>>Wow! It is exactly what I told about.
>>I didn't say what Xserver's driver does with one-byte codes.
>>Actually it does:
>>- converts 0xe0 sequences to some one byte code
>>- and then adds 8 to every code, including one-byte scan-codes and codes
>>(one-byte too) got from the sequences covertion.
>>
>> Therefore 0x5c code after that becomes 5c+8 = 0x64 hex or 100 dec.
>>And the Left arrow sequence at the first step is converted to 0x5c too and
>>after adding 8 becomes 100 (dec).
>
>The X server's driver uses codes (like 0x5c) that it doesn't expect to
>ever see as input to encode the 0xe0 0xXX two-byte codes.
>
>We have a KEY_KP_Equal value defined in common/atKeynames.h: 0x76 (+8 = 126).
>This conflicts with the value used for in xkbcomp/keycodes/xfree86.
>
>My suggestion would be the following patch for the XFree86 DDX, and
>assign to a different value, assign to 126 in
>xkbcomp/keycodes/xfree86, (and make to a keysym in the appropriate
>places).
>
>Index: xc/programs/Xserver/hw/xfree86/common/xf86Events.c
>===
>RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/common/xf86Events.c,v
>retrieving revision 3.149
>diff -u -r3.149 xf86Events.c
>--- xc/programs/Xserver/hw/xfree86/common/xf86Events.c 3 Apr 2003 16:20:23 -
> 3.149
>+++ xc/programs/Xserver/hw/xfree86/common/xf86Events.c 9 Jun 2003 19:23:10 -
>@@ -456,8 +456,14 @@
> case 0x72:scanCode = KEY_AltLang; break; /* AltLang(right) */
> case 0x73:scanCode = KEY_RCtrl;break; /* not needed */
> }
>+ } else
>+#else /* i386 && SVR4 */
>+ {
>+switch (scanCode) {
>+case 0x5C:scanCode = KEY_KP_Equal;break; /* Keypad Equal */
>+}
> }
>-#endif /* i386 && SVR4 */
>+#endif /* !(i386 && SVR4) */
>
> #ifdef __linux__
> if (xf86Info.kbdCustomKeycodes) {
The following might be a better patch for xf86Events.c, because these
conversions should only happen with there is no scan prefix.
Index: xc/programs/Xserver/hw/xfree86/common/xf86Events.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/common/xf86Events.c,v
retrieving revision 3.149
diff -u -r3.149 xf86Events.c
--- xc/programs/Xserver/hw/xfree86/common/xf86Events.c 3 Apr 2003 16:20:23 -
3.149
+++ xc/programs/Xserver/hw/xfree86/common/xf86Events.c 9 Jun 2003 19:52:16 -
@@ -440,25 +440,6 @@
goto special;
#endif /* __sparc__ */
-#if defined (i386) && defined (SVR4)
-/*
- * PANIX returns DICOP standards based keycodes in using 106jp
- * keyboard. We need to remap some keys.
- */
- if(xf86Info.panix106 == TRUE){
-switch (scanCode) {
-case 0x56:scanCode = KEY_BSlash2; break; /* Backslash */
-case 0x5A:scanCode = KEY_NFER; break; /* No Kanji Transfer*/
-case 0x5B:scanCode = KEY_XFER; break; /* Kanji Tranfer */
-case 0x5C:scanCode = KEY_Yen; break; /* Yen curs pgup */
-case 0x6B:scanCode = KEY_Left; break; /* Cur Left */
-case 0x6F:scanCode = KEY_PgUp; break; /* Cur PageUp */
-case 0x72:scanCode = KEY_AltLang; break; /* AltLang(right) */
-case 0x73:scanCode = KEY_RCtrl;break; /* not needed */
-}
- }
-#endif /* i386 && SVR4 */
-
#ifdef __linux__
if (xf86Info.kbdCustomKeycodes) {
specialkey = SpecialServerMap[scanCode];
@@ -489,6 +470,30 @@
break;
#endif
}
+#if defined (i386) && defined (SVR4)
+/*
+ * PANIX returns DICOP standards based keycodes in using 106jp
+ * keyboard. We need to remap some keys.
+ */
+if(xf86Info.panix106 == TRUE){
+ switch (scanCode) {
+ case 0x56:scanCode = KEY_BSlash2;break; /* Backslash */
+ case 0x5A:scanCode = KEY_NFER; break; /* No Kanji Transfer*/
+ case 0x5B:scanCode = KEY_XFER; break; /* Kanji Tranfer */
+ case 0x5C:scanCode = KEY_Yen;break; /* Yen curs pgup */
+ case 0x6B:scanCode = KEY_Left; break; /* Cur Left */
+ case 0x6F:scanCode = KEY_PgUp; break; /* Cur PageUp */
+ case 0x72:scanCode = KEY_AltLang;break; /* AltLang(right) */
+ case 0x73:scanCode = KEY_RCtrl; break; /* not needed */
+ }
+} else
+#else /* i386 && SVR4 */
+{
+ switch (scanCode) {
+ case 0x5c:scanCode = KEY_KP_Equal; brea
Re: iBook us-keyboard problem
> +#if defined (i386) && defined (SVR4)
> +/*
> + * PANIX returns DICOP standards based keycodes in using 106jp
> + * keyboard. We need to remap some keys.
> + */
> +if(xf86Info.panix106 == TRUE){
> + switch (scanCode) {
> + case 0x56:scanCode = KEY_BSlash2; break; /* Backslash */
> + case 0x5A:scanCode = KEY_NFER; break; /* No Kanji
> Transfer*/ + case 0x5B:scanCode = KEY_XFER; break; /* Kanji
> Tranfer */ + case 0x5C:scanCode = KEY_Yen; break; /* Yen curs
> pgup */ + case 0x6B:scanCode = KEY_Left; break; /* Cur Left
> */ + case 0x6F:scanCode = KEY_PgUp; break; /* Cur PageUp */ +
> case 0x72:scanCode = KEY_AltLang;break; /* AltLang(right) */
> + case 0x73:scanCode = KEY_RCtrl;break; /* not needed */ +
>}
> +} else
> +#else /* i386 && SVR4 */
> +{
> + switch (scanCode) {
> + case 0x5c:scanCode = KEY_KP_Equal; break; /* Keypad Equal */
> + }
> +}
> +#endif /* !(i386 && SVR4) */
>}
>
>else if (
>
>
> I'll commit this (and the rest of the patch). Could someone test it
> and let us know if it works correctly?
Looking at the patch and xf86Events.c, I don't understand why this switch code
is if'ed out for the i386/SVR4 case. Is that a special configuration for
Japanese keyboards that don't have KPEQ?
Thanks for your help with this,
Frank
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: iBook us-keyboard problem
On Wed, Jun 11, 2003 at 05:57:25PM +0200, Frank Murphy wrote:
>
>> +#if defined (i386) && defined (SVR4)
>> +/*
>> + * PANIX returns DICOP standards based keycodes in using 106jp
>> + * keyboard. We need to remap some keys.
>> + */
>> +if(xf86Info.panix106 == TRUE){
>> + switch (scanCode) {
>> + case 0x56:scanCode = KEY_BSlash2; break; /* Backslash */
>> + case 0x5A:scanCode = KEY_NFER;break; /* No Kanji
>> Transfer*/ + case 0x5B:scanCode = KEY_XFER; break; /* Kanji
>> Tranfer */ + case 0x5C:scanCode = KEY_Yen; break; /* Yen curs
>> pgup */ + case 0x6B:scanCode = KEY_Left;break; /* Cur Left
>> */ + case 0x6F:scanCode = KEY_PgUp; break; /* Cur PageUp */ +
>> case 0x72:scanCode = KEY_AltLang; break; /* AltLang(right) */
>> + case 0x73:scanCode = KEY_RCtrl; break; /* not needed */ +
>>}
>> +} else
>> +#else /* i386 && SVR4 */
>> +{
>> + switch (scanCode) {
>> + case 0x5c:scanCode = KEY_KP_Equal; break; /* Keypad Equal */
>> + }
>> +}
>> +#endif /* !(i386 && SVR4) */
>>}
>>
>>else if (
>>
>>
>> I'll commit this (and the rest of the patch). Could someone test it
>> and let us know if it works correctly?
>
>Looking at the patch and xf86Events.c, I don't understand why this switch code
>is if'ed out for the i386/SVR4 case. Is that a special configuration for
>Japanese keyboards that don't have KPEQ?
It shouldn't be #if'd out for that case (I'll fix that), but the
i386/SVR4-specific case is for a platform where 0x5C (and some
other codes) is generated for other, Japanese-specific, keys.
Have you tested whether it fixes the KP_Equal problem you reported?
David
--
David Dawes
Founder/committer/developer The XFree86 Project
www.XFree86.org/~dawes
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
