New X11 using HAL to configure input devices, such as mouse and keyboard. I'm applying additional keyboard tweaks with xmodmap. I found that after remapping some keys, the method of keyboard layout switching changes back to default, and mystically changes behaviour of some keys (for example, after xmodmap usage, shortcut "Shift+F6" in midnight commander renders me to tty6 from X-session, and I cannot return back w/o manually killing X-server). I'm using Apple's keboard ( http://store.apple.com/us/product/MB110LL/A?fnode=MTY1NDA1Mg&mco=MjE0Njk1Ng ) so remapping of keys (functional keys, for example) is essential. Here is my keyboard config for HAL: http://peter.fedorapeople.org/F-10/10-x11-input.fdi Here is my xmodmap's remapping config: http://peter.fedorapeople.org/F-10/xmodmap.conf
...and Xorg-log too: http://peter.fedorapeople.org/F-10/Xorg.0.log
Created attachment 325005 [details] xmodmap.conf
Created attachment 325006 [details] 10-x11-input-fdi.xml
Created attachment 325007 [details] /var/log/Xorg.0.log
Switching to evdev changes a number of keycodes and you'll have to adjust your xmodmap.conf accordingly. However, I find your xmodmap.conf excessive. Why do you need to redefine every single key? You should just leave everything up to xkb and just replace those you're not happy with. run setxkbmap -layout "us,ru" -option "grp:caps_toggle,grp_led:caps" -model "macintosh" and see if the keys work. If not, please specify which keys (or groups of keys) don't work and we'll narrow down what xkb options you actually need.
This issue was gone, then I switched to 16-bit mode.
Oops, wrong url! :) Sorry for previous comment.
Created attachment 326859 [details] latest xmodmap.conf
Ok, I tried to narrow this bug. Here is my today's report: * running # setxkbmap -layout "us,ru" -option "grp:caps_toggle,grp_led:caps" -model "macintosh" resets my previous xmodmap settings (so I don't need to restart my X every time just to test my new remapping :) - thanks for hint! * Here is my latest xmodmap.conf (see attached file) - i need only to remap functional keys. * Remapping keycode 49 = less greater slash bar bar brokenbar keycode 94 = grave asciitilde Cyrillic_io Cyrillic_IO keycode 191 = Insert is harmless, but every my attempt to remap functional keys is failed. Let's take, for example, my attempt to remap F1 key. Default mapping is keycode 67 = F1 XF86_Switch_VT_1 F1 XF86_Switch_VT_1 F1 XF86_Switch_VT_1 keycode 232 = XF86MonBrightnessDown NoSymbol XF86MonBrightnessDown NoSymbol XF86MonBrightnessDown That means, that (by default) I need to press 'fn' special key to F1 behave as F1 (keycode 67). http://images.apple.com/keyboard/images/gallery/wired_1_20070813.jpg ('fn' key is situated above the 'delete' key, where 'insert' usually placed - that's why I remapped F13 with 'insert' In order to do so I added the following lines in xmodmap.conf: keycode 232 = F1 XF86_Switch_VT_1 F1 XF86_Switch_VT_1 F1 XF86_Switch_VT_1 keycode 67 = XF86MonBrightnessDown NoSymbol XF86MonBrightnessDown NoSymbol XF86MonBrightnessDown (It worked with F-9. btw). xev recognises that F1 became F1 w/o pressed 'fn' and became 'keycode 232' with pressed 'fn', but in console with 'Alt' pressed, xterm recognises it as 'P' (just outputs 'P' sign), which annoys me, because I mapped Alt+F1 to 'switch to 1st workplace'. I'm already got accustomed with the fact that something will be broken with every new Fedora release, I didn't remember when exactly functional keys (F1, F2,... F15) became accessible only with special 'fn' key pressed - I just remapped them at that time (swapped values with pressed 'fn' and w/o) :).
Maybe this is a bug in fvwm?
I need the output of xev in all cases please. xev will tell you the keysym assigned to a particular key.
Hello. I just found that this issue was gone! Can't say what particular update solved this issue. I think that this ticket may be closed with "nextrelease"
Thanks for letting us know. Hopefully, Fedora will be now more known in the Russia for its ability to fix problems than for its brokeness. :)