Forwarding this bug from Ubuntu reporter iWatch: http://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/465926 Another sun keyboard bug, which affects type 6 (and reportedly type 7). [Original Description] just upgraded to 9.10 ... my backspace key no longer works, system wide. i have a sun type 6 (terminal keyboard layout) the correct layout is not shown when i select add from system->pref->key board it does show that i have a Sun Type 5/6 .. but a type 5 is not the same a type 6 I was able to work-around this bug (got my backspace key to work) by selecting "generic 105-key" Keycode 22, which is backspace, simply isn't defined. xmodmap -pk reports no definition, and xev accordingly reports it as "NoSymbol". A temporary workaround is this: xmodmap -e "keycode 22 = BackSpace" But of course that gets lost when the X session is finished. Architecture: i386 Date: Fri Oct 30 20:54:35 2009 DistroRelease: Ubuntu 9.10 ExecutablePath: /usr/bin/yelp NonfreeKernelModules: nvidia Package: yelp 2.28.0-0ubuntu2 ProcEnviron: PATH=(custom, user) LANG=en_US.UTF-8 SHELL=/bin/ksh ProcVersionSignature: Ubuntu 2.6.31-14.48-generic SourcePackage: yelp Uname: Linux 2.6.31-14-generic i686
If you do not use xmodmap - what do you see in xev utility when pressing Backspace? Also, could you please try the following: in keycodes/sun, find the section "type6" and append <BKSP> = 22;
sorry, I missed the (obvious) fact that Q was for me... no I don't use xmodmap, my work-a-round has been to use a "generic 105" changing back to Sun type5/6 the problem does reappear... the following is the output of a key press and release from xev: KeyPress event, serial 33, synthetic NO, window 0x4e00001, root 0x1a7, subw 0x0, time 81004713, (-3,37), root:(3578,930), state 0x30, keycode 22 (keysym 0x0, NoSymbol), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 36, synthetic NO, window 0x4e00001, root 0x1a7, subw 0x0, time 81004817, (-3,37), root:(3578,930), state 0x30, keycode 22 (keysym 0x0, NoSymbol), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False as compared to this with "generic 105" KeyPress event, serial 33, synthetic NO, window 0x4e00001, root 0x1a7, subw 0x4e00002, time 81202105, (49,40), root:(3630,933), state 0x30, keycode 22 (keysym 0xff08, BackSpace), same_screen YES, XLookupString gives 1 bytes: (08) " XmbLookupString gives 1 bytes: (08) " XFilterEvent returns: False KeyRelease event, serial 36, synthetic NO, window 0x4e00001, root 0x1a7, subw 0x4e00002, time 81202209, (49,40), root:(3630,933), state 0x30, keycode 22 (keysym 0xff08, BackSpace), same_screen YES, XLookupString gives 1 bytes: (08) " XFilterEvent returns: False I'm sorry, you'll need to explain these instructions a little better: "Also, could you please try the following: in keycodes/sun, find the section "type6" and append <BKSP> = 22;" Is there a config file "sun" in a directory keycodes in the tree somewhere?
> I'm sorry, you'll need to explain these instructions a little better: > "Also, could you please try the following: in keycodes/sun, > find the section "type6" and append <BKSP> = 22;" > Is there a config file "sun" in a directory keycodes in the tree somewhere? Check /usr/share/X11/xkb/keycodes/sun. There must be a section for "type6"
yes, there is a section "type6" which looks like this: xkb_keycodes "type6" { include "sun(type5)" }; a few lines below that is a definition for "type6_usb" (included here): // Even though this is labeled as _usb, I verified these keycodes as accurate // on my type5 serial and type6 serial keyboards as well on linux-2.6 boxes. // I'm not sure where the "type5" keycodes above are coming from... xkb_keycodes "type6_usb" { include "xfree86" <STOP> = 232; <AGAI> = 133; <PROP> = 134; <UNDO> = 135; <FRNT> = 140; <COPY> = 248; <OPEN> = 191; <PAST> = 192; <FIND> = 122; <CUT> = 188; <HELP> = 245; // The blank has keycode 239 on my type6 serial kb, but 134 on // my type6 usb keyboard (same as <PROP>) <BLNK> = 239; // AltGr + PrScr actually sends a different keycode <SYRQ> = 92; <MUTE> = 160; <VOL-> = 174; <VOL+> = 176; <POWR> = 222; indicator 4 = "Compose"; }; I don't recall type6_usb being offered as a choice from the keyboard GUI, but it does seem to be more corect for my (USB) type 6 keyboard. when I get home tonight I try renaming type6_usb to type6 (and comment the existing type6)
Actually if you try "setxkbmap -rules base -model sun6 -print" You'll see it is using keycodes from type6_usb (The GUI does not offer keycodes! It deals with models, which are translated into keycodes using rules/base or rules/evdev depending on your driver) Actually, could you please provide the results of xprop -root | grep XKB
I only have ssh access to the machine right now (I did make the change in the keycodes/sun file, that is renamed type6 to type6_usb that now includes type6, and renamed type6_usb to type6) also remember that my current keyboard is "generic 105-key", with that in mind, here is the output of the two commands: $ setxkbmap -rules base -model sun6 -print xkb_keymap { xkb_keycodes { include "sun(type6_usb)+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "sun_vndr/us(type6)" }; xkb_geometry { include "pc(pc104)" }; }; $ xprop -root | grep XKB _XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc105", "us", "", "" _XKB_RULES_NAMES(STRING) = "xorg", "pc104", "us", "", ""
That's amazing. Why does not your X use evdev driver??? > $ xprop -root | grep XKB > _XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc105", "us", "", "" > _XKB_RULES_NAMES(STRING) = "xorg", "pc104", "us", "", "" Anyway, when you choose "Sun Type 5/6", it actually picks the model sun6 which is translated to keycodes type6_usb. Please choose that "bad" keyboard and try "setxkbmap -print" - you'll see
lol you tell me... I'm just a C dev with an ubuntu box, not an X11 dev! I'll try it when I get home... 60 min. on a side note: if you can point me to some "quick start document" ;) for the geometry file, I'll fix the sun type6 entry :) xkb_geometry "t6" { // This is an approximate layout for a (US/ASCII) Sun Type6 // keyboard. I just took a similar layout (101 key PC keyboard) // and adjusted the sizes. width= 515; height= 170; shape "EDGE" { cornerRadius= 2, { [ 515, 170 ] } }; shape.cornerRadius= 1; shape "NORM" { { [ 18,18] }, { [2,1], [16,17] } }; shape "BKSP" { { [ 37,18] }, { [2,1], [35,17] } }; shape "TABK" { { [ 27,18] }, { [2,1], [25,17] } }; ... what are the three pairs?
http://www.charvolant.org/~doug/xkb/html/node5.html#SECTION00056000000000000000
switched to sun/type6 (my backspace key is now broken) $ xprop -root | grep XKB _XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "pc105", "us", "", "" _XKB_RULES_NAMES(STRING) = "evdev", "sun6", "us", "", "" $ setxkbmap -print xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "sun_vndr/us(type6)+inet(evdev)" }; xkb_geometry { include "pc(pc104)" }; }; another data point... I powered up an old ubuntu 9.04 box, it uses the sun/type6 without issue. the output from the above two commands is identical. I diff'ed the two keycode files and the only diffs were the changes I just made.
I haven't fully tested this (but xkbprint draws a pretty picture, finally) I started with the output of "xkbcomp :0.0", not with the individual config files (which is why I haven't fully tested it) I think I could "install" it with a "xkbcomp sun-type6.xkm :0.0" but I'm not sure if that's a persistent change, or just for the current X session, need more time to read.
Created attachment 44786 [details] sun-type6.xkb xkbcomp sun-type6.xkb;xkbprint -color sun-type6.xkm;ps2pdf sun-type6.ps the "Super" keys don't display on the pdf
In your file there is absolutely correct <BKSP> = 22; and also correct key <BKSP> { type= "CTRL+ALT", symbols[Group1]= [ BackSpace, Terminate_Server ] }; So why are you saying it is broken??
I originally posted the problem on a ubuntu bug site. Bryce (kindly) reposted the bug here, since (I assume) he thought it was a bug with the underlying xkb and not something unique to ubuntu. He then asked me to register here to assist with additional data. The file I uploaded was a (from scratch) "comprehensive" (yet not fully tested) definition for the Sun type6 (usb) keyboard. You've explained some things and pointed me to documentation (all very helpful, thanks!). But you've now confused me by saying, "your file works, why claim it's broken?" The point is, it's MY file, not the one that ships w/ Ubuntu (or any distro.) ... and (not that we need one, but) it doesn't explain why it worked in Ubuntu 9.04 but broke in 9.10, even though the config files were the same. (OHHHHH ... ok, I just re-read the entire thread top to bottom....) my "it's still broken" comment was posted 2 days before I created my from scratch xkb file. I was referring to the changes I made to the existing /usr/share/X11/xkb/keycodes/sun. I'm so glad for timestamps on comments... untold millions have probably died in wars over stuff like this! I need to separate the changes from my .xkb file into the (geometry/keycodes/keymap/symbols) files and test it, and then submit a patch ... unless you have a better way :)
Oops, sorry. But the thing is that BKSP=22 even in the current keycodes/evdev. So could you try the following: 1. configure xkb normally to use sun6 model 2. do xkbcomp :0 -xkb out.xkb 3. Attach out.xkb here I would be surprised if it does not have proper BKSP
Created attachment 44805 [details] requested data as requested ... it does have a keycode for <BKSP> = 22; but it's missing the link from <BKSP> to BackSpace in the symbol section. (also the geometry is WAY off)
so in the file /usr/share/X11/xkb/symbols/sun_vndr/us I added the <BKSP> for type 6 xkb_symbols "type6" { include "sun_vndr/us(sunbasic)" include "sun_vndr/us(volumekeys)" include "eurosign(4)" key <SYRQ> { [ SunSys_Req ]}; key <BKSP> { [ BackSpace ]}; // added }; then when I select Sun-type6, wala! backspace works :) ... I might actually understand this! but those Sun config files seem to be in disarray, and the one line I added seems like a hack, probably only fixed that single type.
But you do not have to do that! If you look at sun_vndr/us(sunbasic) - it already includes key <BKSP> { [ BackSpace ] }; Do you have that line (#95)?
nope... only the one I added: $ cd /usr/share/X11/xkb/symbols/sun_vndr/ $ ls cs dk fr hu ko nl pt solaris tuv usb cz es gb it lt no ru sw tw de fi gr jp lv pl se tr us $ grep BKSP * jp: key <BKSP> { [ BackSpace ] }; jp: key <BKSP> { [ BackSpace ] }; jp: key <BKSP> { [ BackSpace ] }; jp: key <BKSP> { [ BackSpace ] }; jp: key <BKSP> { [ BackSpace ] }; us: key <BKSP> { [ BackSpace ]};
Created attachment 44853 [details] all xkb config files these are "stock" Ubuntu 9.10 with the exception of keycodes/sun symbols/sun_vndr/us which have minor changes as discussed in this thread
http://cgit.freedesktop.org/xkeyboard-config/tree/symbols/sun_vndr/us See, there is BKSP there. It means it is already fixed upstream. Should we close this bug?:)
U9.10 is sooo old ;)
I won't oppose closing this bug. It would be nice if the work I did in the file sun-type6.xkb could be incorporated into the official tree. Bryce, your thoughts?
Well, as you can see, your changes are already there - in slightly different form:) Really, try xk-c from git.
On Fri, Mar 25, 2011 at 09:21:28AM -0700, bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=34368 > > --- Comment #23 from iWatch <david.t.kerns@gmail.com> 2011-03-25 09:21:26 PDT --- > I won't oppose closing this bug. It would be nice if the work I did in the file > sun-type6.xkb could be incorporated into the official tree. > > Bryce, your thoughts? I'm fine with closing the bug as well; it sounds like the general issue is already fixed in the stock tree, and the core issue was more pertaining to your locally adjusted configuration. So yeah, I'll go ahead and close out the bug on the ubuntu side too.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.