From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) Description of problem: This ist not really a bug, but as far as I know there are many people like me, who have the wish, that their Sun USB Type 6 Keyboard would be supported. There are some additional keys, which would be nice for use, but just simple support under X would be fine: A gkb_xmmap us works, but refuses the . button from to work and a gkb_xmmap us-sun (which is for the Tyoe 5 Keyboard, but the both keyboards should have the same layout, or at least the same keycodes) makes it impossible to work with the keyboard (it changes the layout in a way, that you can only type the chars with the num keys). Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Sun USB Type 6 Keyboard 2. 3. Additional info: There is a workaround for the keyboard: http://www.infosun.fmi.uni-passau.de/~nils/type6/ but this requires manual compiling of the X Server and it is only for the german version of this keyboard. Plus I don't really know who this affects the RedHat patched X-Server.
I believe someone here at Red Hat has sent me patches for this keyboard. I will try to get them integrated into upstream as well as rawhide.
I havent found them. If someone attaches patches against stock XFree86 4.2.0 source code (not the installed files), I'll include it if it patches cleanly. Just reopen bug report with patch attached.
The latest patch I found was for XFree 4.0.3. It seems that non of the both developers is going to update his system to 4.1.0 or 4.2.0, so there won't be any patches from them. But maybe there is someone other who knows to patch the newer versions. I've included the 4.0.3 patch below: --- xf86Events.c.orig Fri Apr 27 15:41:14 2001 +++ xf86Events.c Thu Apr 26 23:01:28 2001 @@ -377,6 +377,14 @@ if (xf86Info.scanPrefix == 0) { switch (scanCode) { + + case 0x5d: scanCode = 0xD7; break; /* AGAI, SunAgain */ + case 0x5e: scanCode = 0xD8; break; /* PROP, SunProps */ + case 0x5f: scanCode = 0xD9; break; /* UNDO, SunUndo */ + case 0x62: scanCode = 0xDA; break; /* FRNT, SunFront */ + case 0x64: scanCode = 0xDC; break; /* OPEN, SunOpen */ + case 0x65: scanCode = 0xDD; break; /* PAST, SunPaste */ + case KEY_Prefix0: case KEY_Prefix1: #if defined(PCCONS_SUPPORT) || defined(SYSCONS_SUPPORT) || defined (PCVT_SUPPORT) @@ -427,6 +435,22 @@ case KEY_F6: scanCode = KEY_F16; break; case KEY_F7: scanCode = KEY_F17; break; case KEY_KP_Plus: scanCode = KEY_KP_DEC; break; + /* NE: again for Type 6. Map prefixed scancodes to keycodes + xkb/keycodes/xfree86(type6) -10 */ + case 0x68: scanCode = 0xD6; break; /* SunStop */ + case 0x78: scanCode = 0xDB; break; /* SunCopy */ + case 0x65: scanCode = 0xDE; break; /* SunFind */ + case 0x3c: scanCode = 0xDF; break; /* SunCut */ + case 0x62: scanCode = 0xE0; break; /* SunHelp */ + case 0x5f: scanCode = 0xD9; break; /* UNDO, SunUndo */ + case 0x64: scanCode = 0xDC; break; /* OPEN, SunOpen */ + + /* NE: these are only -8 (GLYPH_OFFSET) */ + case 0x26: scanCode = 157; break; /* SunMute */ + case 0x25: scanCode = 151; break; /* VOL- */ + case 0x1e: scanCode = 150; break; /* VOL+ */ + case 0x5e: scanCode = 152; break; /* SunPower */ + /* * Ignore virtual shifts (E0 2A, E0 AA, E0 36, E0 B6) */
Just for the record: I am the author of the above mentioned workaround. I do have newer patches ready. As much as I would like to have them in the RH distributions, it's probably not feasible. The reason for the X server patch is that the keyboard legacy driver remaps keycodes for some reason. As a result, some of the extra (non 102-PC) keys of the Type 6 keyboard have the same "X" keycode, in other words: they are indistinguishable. So I had to remap some of them onto unused keycodes. Now I can't say with authority that these - by the Type 6 keyboard - unused keycodes aren't being use by some other keyboard, which, up to now, works fine with X, but wouldn't work after applying my patch. The general solution would be to replace the leagacy keyboard driver. This has been acknowledged by the XFree86 team (http://www.xfree86.org/pipermail/xpert/2000-August/000545.html), but to my knowledge no work has been done so far.