LinuxQuestions.org - F keys lose functionaity after them switching back from "Multimedia" mode

Hi,

as I recently acquired a minimalistic keyboard with no multimedia keys, I wanted to restore their functionality by replacing the seldomly-used F keys, but still be able to use the F keys when needed.

In order to do that without having to hold down a modifier for either mode, I wrote two simple .Xmodmaps and a shell script to toggle between the two.

.Xmodmap-F:

Code:

keycode 67 = F1

keycode 68 = F2

keycode 69 = F3

keycode 70 = F4

...

.Xmodmap-M:

Code:

keycode 67 = XF86AudioMute

keycode 68 = XF86AudioLowerVolume

keycode 69 = XF86AudioRaiseVolume

keycode 70 = F4

keycode 71 = XF86AudioPlay

...

No further content in there except the continued list of F keys.

Well, starting out with the standard F behavior with F1 as an example, xev tells me:

Code:

KeyPress event, serial 35, synthetic NO, window 0x1800001,

    root 0x15a, subw 0x0, time 353065814, (55,96), root:(735,115),

    state 0x10, keycode 67 (keysym 0xffbe, F1), same_screen YES,

    XLookupString gives 0 bytes: 

    XmbLookupString gives 0 bytes: 

    XFilterEvent returns: False

There is no difference when executing xmodmap .Xmodmap-F.

If I execute xmodmap .Xmodmap-M, xev says:

Code:

MappingNotify event, serial 59, synthetic NO, window 0x0,

    request MappingKeyboard, first_keycode 67, count 1

No problems there; F1 now gives:

Code:

KeyPress event, serial 71, synthetic NO, window 0x1800001,

    root 0x15a, subw 0x0, time 353292537, (53,92), root:(733,111),

    state 0x10, keycode 67 (keysym 0x1008ff12, XF86AudioMute), same_screen YES,

    XKeysymToKeycode returns keycode: 10

    XLookupString gives 0 bytes: 

    XmbLookupString gives 0 bytes: 

    XFilterEvent returns: False

Still working, execute xmodmap .Xmodmap-F:

Code:

MappingNotify event, serial 83, synthetic NO, window 0x0,

    request MappingKeyboard, first_keycode 67, count 1

Seems fine. However, F1 now reads:

Code:

KeymapNotify event, serial 32, synthetic NO, window 0x0,

    keys:  90  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  

          0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0

And even though the focus is grabbed by the xev window, which normally prevents media key usage, the mute function is activated. The message above is _the same_ for any function key formerly defined as a multimedia key - however, F4, which I did not use previously, still reads:

Code:

KeyRelease event, serial 35, synthetic NO, window 0x2000001,

    root 0x15a, subw 0x0, time 356496666, (80,81), root:(760,100),

    state 0x10, keycode 70 (keysym 0xffc1, F4), same_screen YES,

    XLookupString gives 0 bytes: 

    XFilterEvent returns: False

There are three things which make this even stranger:

First, this does not happen every time, but only after toying around with the script I wrote for a while. (Nothing fancy in there, just calls osd_cat to tell me which mode it's now in, writes the current state to disk, and loads the appropriate Xmodmap.)

Second, the keys still work - but only one layer up, i. e. if I press shift+f1 when it should be in multimedia mode, it is there, and the same is true if it should be in function key mode.

Third, and I have not been able to definitely confirm this as the problem doesn't appear all the time, this only seems to happen for the F keys. I. e. if I were to substitute number keys, it would work. (Being impractical, of course, as I need these.)

As soon as this slipup has happened once, there is no way back except restarting X, as reloading a default .Xmodmap or unloading my WMs language module do nothing.

I'm running an up-to-date Aptosid (derived from Debian Unstable) and e17 ecomorph as a WM, with an Enermax Acrylux Wireless (great piece of hardware, btw) keyboard managed by evdev. If you need any more information, I'll be glad to provide it.

Thanks for any advice,
V