Bug 473437 - xmodmap conflicts with evdev
xmodmap conflicts with evdev
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-28 09:43 EST by Peter Lemenkov
Modified: 2010-01-29 10:09 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-19 18:58:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
xmodmap.conf (12.83 KB, text/plain)
2008-11-28 10:29 EST, Matěj Cepl
no flags Details
10-x11-input-fdi.xml (707 bytes, text/plain)
2008-11-28 10:30 EST, Matěj Cepl
no flags Details
/var/log/Xorg.0.log (52.53 KB, text/plain)
2008-11-28 10:30 EST, Matěj Cepl
no flags Details
latest xmodmap.conf (1.75 KB, text/plain)
2008-12-14 06:02 EST, Peter Lemenkov
no flags Details

  None (edit)
Description Peter Lemenkov 2008-11-28 09:43:22 EST
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
Comment 1 Peter Lemenkov 2008-11-28 09:45:19 EST
...and Xorg-log too:

http://peter.fedorapeople.org/F-10/Xorg.0.log
Comment 2 Matěj Cepl 2008-11-28 10:29:46 EST
Created attachment 325005 [details]
xmodmap.conf
Comment 3 Matěj Cepl 2008-11-28 10:30:16 EST
Created attachment 325006 [details]
10-x11-input-fdi.xml
Comment 4 Matěj Cepl 2008-11-28 10:30:43 EST
Created attachment 325007 [details]
/var/log/Xorg.0.log
Comment 5 Peter Hutterer 2008-11-30 20:37:29 EST
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.
Comment 6 Peter Lemenkov 2008-12-09 02:45:40 EST
This issue was gone, then I switched to 16-bit mode.
Comment 7 Peter Lemenkov 2008-12-09 02:53:34 EST
Oops, wrong url! :)
Sorry for previous comment.
Comment 8 Peter Lemenkov 2008-12-14 06:02:14 EST
Created attachment 326859 [details]
latest xmodmap.conf
Comment 9 Peter Lemenkov 2008-12-14 06:24:03 EST
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) :).
Comment 10 Peter Lemenkov 2008-12-14 06:37:33 EST
Maybe this is a bug in fvwm?
Comment 11 Peter Hutterer 2008-12-14 18:04:59 EST
I need the output of xev in all cases please. xev will tell you the keysym assigned to a particular key.
Comment 12 Peter Lemenkov 2008-12-18 14:08:23 EST
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"
Comment 13 Matěj Cepl 2008-12-19 18:58:55 EST
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. :)

Note You need to log in before you can comment on or make changes to this bug.