Bug 22232 - xkb unable to map key
Summary: xkb unable to map key
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Input/XKB (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Daniel Stone
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords: NEEDINFO
: 17755 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-06-11 07:37 UTC by Alexey Kuznetsov
Modified: 2012-08-08 17:49 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
simple print (57.16 KB, text/plain)
2009-06-13 05:16 UTC, Alexey Kuznetsov
no flags Details
play button (47.43 KB, text/plain)
2009-06-13 05:16 UTC, Alexey Kuznetsov
no flags Details
full print (47.49 KB, text/plain)
2009-06-13 05:17 UTC, Alexey Kuznetsov
no flags Details

Description Alexey Kuznetsov 2009-06-11 07:37:27 UTC
I'm not sure which component affected to my bug report, for first lets attach it to xkeyboard-confg package :)

I have notebook Macbook Pro, with linux on board it works perfectly except some small issues. One issue related to keyboard. That is default keys map is not so good.

You can check how Macbook Pro keyboard look like:

http://support.apple.com/kb/HT1220

As normal usage, i prefer to have several keys map. I prefer to switch 'Left Alt' key with 'Left Windows Key' (Super_L), map small enter key (KPEN) with 'Delete' key, and either Eject to Print key.

Here the list:
- Super_L to Alt_L
- Alt_L to Super_L
- KP_Enter to Delete
- Eject to Print

First two rules can be done easily by using Layout options in gnome-keyboard-property application.

For two last rules i made my own Layout options. I map enter to delete, key with no problems. But when i made rules for Eject key, it wont work.

When i press Eject key it appear as Print key in xev application. My gnome keyboard shortcut set to run print screen application. But when i press eject key on my workspace, noting happens.

I also tried to map other key to check if it my fault or not. When i map KP_Enter to Print key everything works fine. But when i map Eject to Print noting going to work.

In my opinion here bug in X11, but i do not know where it is.

Here is my patch for it.
Comment 1 Sergey V. Udaltsov 2009-06-12 09:22:19 UTC
> - KP_Enter to Delete
What's formal reason for that change? Is it working like that in MacOS - or just matter of your preference?

> When i press Eject key it appear as Print key in xev application.
Can you show me the output here please?

> My gnome
> keyboard shortcut set to run print screen application. But when i press eject
> key on my workspace, noting happens.
Can that be a gnome bug? Can you try to use that key in some non-gnome (non-gtk) app?
Comment 2 Alexey Kuznetsov 2009-06-12 09:31:30 UTC
(In reply to comment #1)
> > - KP_Enter to Delete
> What's formal reason for that change? Is it working like that in MacOS - or
> just matter of your preference?
> 

Two enter keys placed close to each other, look not smart. Its my preferences. I like to see it work in this way.

> > When i press Eject key it appear as Print key in xev application.
> Can you show me the output here please?
> 

First i press Space key, then Eject, then Space key again (you can see some garbage as MappingNotify event produced by eject key):

KeyPress event, serial 27, synthetic NO, window 0x5400001,
    root 0x77, subw 0x0, time 9382253, (103,311), root:(109,374),
    state 0x0, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XmbLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

KeyRelease event, serial 30, synthetic NO, window 0x5400001,
    root 0x77, subw 0x0, time 9382349, (103,311), root:(109,374),
    state 0x0, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

MappingNotify event, serial 30, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

MappingNotify event, serial 30, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 247

KeyPress event, serial 30, synthetic NO, window 0x5400001,
    root 0x77, subw 0x0, time 9382693, (103,311), root:(109,374),
    state 0x0, keycode 169 (keysym 0xff61, Print), same_screen YES,
    XKeysymToKeycode returns keycode: 107
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x5400001,
    root 0x77, subw 0x0, time 9382757, (103,311), root:(109,374),
    state 0x0, keycode 169 (keysym 0xff61, Print), same_screen YES,
    XKeysymToKeycode returns keycode: 107
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

MappingNotify event, serial 32, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

MappingNotify event, serial 32, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 247

KeyPress event, serial 32, synthetic NO, window 0x5400001,
    root 0x77, subw 0x0, time 9382957, (103,311), root:(109,374),
    state 0x0, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XmbLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x5400001,
    root 0x77, subw 0x0, time 9383037, (103,311), root:(109,374),
    state 0x0, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False


> > My gnome
> > keyboard shortcut set to run print screen application. But when i press eject
> > key on my workspace, noting happens.
> Can that be a gnome bug? Can you try to use that key in some non-gnome
> (non-gtk) app?
> 

I do not understand what do you predict. Which application you suggest to run? Some in global key binding, or some independent application? or what?
Comment 3 Sergey V. Udaltsov 2009-06-12 09:37:20 UTC
> Two enter keys placed close to each other, look not smart. Its my preferences.
> I like to see it work in this way.
Well, IMO it is too exotic and personal, I'd live it to xmodmap...

> KeyPress event, serial 30, synthetic NO, window 0x5400001,
>     root 0x77, subw 0x0, time 9382693, (103,311), root:(109,374),
>     state 0x0, keycode 169 (keysym 0xff61, Print), same_screen YES,
>     XKeysymToKeycode returns keycode: 107
>     XLookupString gives 0 bytes: 
>     XmbLookupString gives 0 bytes: 
>     XFilterEvent returns: False
That looks perfectly correct. I guess, it is not XKB.

> I do not understand what do you predict. Which application you suggest to run?
> Some in global key binding, or some independent application? or what?
Well, what I'd do is run X without GNOME, with some simple window manager where all keybindings can be configured directly in the text file (for example, icewm).

Alternatively I would look again into gnome-keybinding-properties, trying to assign the key to the "Take screenshot" function. There, press your Eject key - whether g-k-p sees it and how it displays the key name.
Comment 4 Alexey Kuznetsov 2009-06-12 09:46:05 UTC
(In reply to comment #3)
> > Two enter keys placed close to each other, look not smart. Its my preferences.
> > I like to see it work in this way.
> Well, IMO it is too exotic and personal, I'd live it to xmodmap...
> 

I made small researching about this problem, xmodmap works buggly. As i suspect you can read russian, here is full article about my research in my blog: http://blog.axet.ru/2009/06/keyboard-mapping-trough-layout-options.html.

In short: xmodmap make wrong mapping for keymodifers, here is only one way to do it: by layout options. Unfortunate, layout options do not solve last problem: mapping eject key to print key.

> > KeyPress event, serial 30, synthetic NO, window 0x5400001,
> >     root 0x77, subw 0x0, time 9382693, (103,311), root:(109,374),
> >     state 0x0, keycode 169 (keysym 0xff61, Print), same_screen YES,
> >     XKeysymToKeycode returns keycode: 107
> >     XLookupString gives 0 bytes: 
> >     XmbLookupString gives 0 bytes: 
> >     XFilterEvent returns: False
> That looks perfectly correct. I guess, it is not XKB.
> 
> > I do not understand what do you predict. Which application you suggest to run?
> > Some in global key binding, or some independent application? or what?
> Well, what I'd do is run X without GNOME, with some simple window manager where
> all keybindings can be configured directly in the text file (for example,
> icewm).

I will try. +

> 
> Alternatively I would look again into gnome-keybinding-properties, trying to
> assign the key to the "Take screenshot" function. There, press your Eject key -
> whether g-k-p sees it and how it displays the key name.
> 

Its detected as "Print" key :)
Comment 5 Alexey Kuznetsov 2009-06-12 10:01:01 UTC
I'm not found Layout options under Xfce 4 but when i applied xmodmap file with similar mapping algorithm i got no print key working (alt/win/enter keys works)

keycode 64 = Super_L
keycode 133 = Alt_L
keycode 134 = Alt_R
keycode 104 = Delete
keycode 169 = Print Sys_Req


Is it answer to your question or not?
Comment 6 Alexey Kuznetsov 2009-06-12 10:09:49 UTC
KDE has Layout options and Print key also does not work. (of course it works when i run xev)

May be problem related to some X11 component, not to xkeyboard-config. I dont know.

Enter->Delete map is very useful same useful as Alt/Win behafiour. And i hope it will be included in next release.
Comment 7 Sergey V. Udaltsov 2009-06-12 15:12:07 UTC
> http://blog.axet.ru/2009/06/keyboard-mapping-trough-layout-options.html.
I read that, thanks. I must admit, your patch is good quality;)

> In short: xmodmap make wrong mapping for keymodifers, 
???? Why would you need modifiers for the Delete key?

> do it: by layout options. Unfortunate, layout options do not solve last
> problem: mapping eject key to print key.
Yes, that's really mystery to me. All my life I trusted xev...

Ok, another thing try. If you map it (using XKB) as, say, ... XF86AudioPlay - will it work?
Comment 8 Alexey Kuznetsov 2009-06-12 20:18:12 UTC
(In reply to comment #7)

> > In short: xmodmap make wrong mapping for keymodifers, 
> ???? Why would you need modifiers for the Delete key?

xmodmap dosn't work correctly with alt/win behavior. enter->del is ok.

> > do it: by layout options. Unfortunate, layout options do not solve last
> > problem: mapping eject key to print key.
> Yes, that's really mystery to me. All my life I trusted xev...
> 
> Ok, another thing try. If you map it (using XKB) as, say, ... XF86AudioPlay -
> will it work?
> 

yes :) i tried with either Enter -> XF86AudioPlay, Eject -> XF86AudioPlay. Booth works fine.
Comment 9 Sergey V. Udaltsov 2009-06-13 05:04:50 UTC
> xmodmap dosn't work correctly with alt/win behavior. enter->del is ok.
Ok, so alt/win you can currently fix using xkb options. I'd leave Enter->del to xmodmap, if you don't mind. The real problem now is eject->print.

> > Ok, another thing try. If you map it (using XKB) as, say, ... XF86AudioPlay -
> > will it work?
> yes :) i tried with either Enter -> XF86AudioPlay, Eject -> XF86AudioPlay.
> Booth works fine.

So, you're saying Eject->Print does not work, while Eject -> XF86AudioPlay works fine, right? Could you please do "xkbcomp :0 -xkb out.xkb" for two situations: when Eject is mapped to Print, when Eject is mapped to AudioPlay.
Comment 10 Alexey Kuznetsov 2009-06-13 05:16:07 UTC
(In reply to comment #9)
> > xmodmap dosn't work correctly with alt/win behavior. enter->del is ok.
> Ok, so alt/win you can currently fix using xkb options. I'd leave Enter->del to
> xmodmap, if you don't mind. The real problem now is eject->print.
> 

right

> > > Ok, another thing try. If you map it (using XKB) as, say, ... XF86AudioPlay -
> > > will it work?
> > yes :) i tried with either Enter -> XF86AudioPlay, Eject -> XF86AudioPlay.
> > Booth works fine.
> 
> So, you're saying Eject->Print does not work, while Eject -> XF86AudioPlay
> works fine, right?

right
Comment 11 Alexey Kuznetsov 2009-06-13 05:16:35 UTC
Created attachment 26750 [details]
simple print
Comment 12 Alexey Kuznetsov 2009-06-13 05:16:55 UTC
Created attachment 26751 [details]
play button
Comment 13 Alexey Kuznetsov 2009-06-13 05:17:16 UTC
Created attachment 26753 [details]
full print

full print also does not work
Comment 14 Alexey Kuznetsov 2009-06-13 05:17:42 UTC
[axet@axet-laptop ~]$ xkbcomp :0 -xkb out-print2.xkb
Warning:          Could not load keyboard geometry for :0
                  BadAlloc (insufficient resources for operation)
                  Resulting keymap file will not describe geometry
[axet@axet-laptop ~]$ 
Comment 15 Sergey V. Udaltsov 2009-06-13 07:11:02 UTC
> Warning:          Could not load keyboard geometry for :0
>                   BadAlloc (insufficient resources for operation)
>                   Resulting keymap file will not describe geometry
Oops. That's a bad sign. It seems something inside XKB (in X server) is broken (not fully initialized).

out-print2 and out-play are practically identical (and out.xkb is basically same - it just has the geometry part). My guess would be that it is something inside X server. So, let's ask Xorg input folks...
Comment 16 Peter Hutterer 2009-09-03 17:34:20 UTC
(In reply to comment #15)
> > Warning:          Could not load keyboard geometry for :0
> >                   BadAlloc (insufficient resources for operation)
> >                   Resulting keymap file will not describe geometry
> Oops. That's a bad sign. It seems something inside XKB (in X server) is broken
> (not fully initialized).

fwiw, that was a bug somewhere in XKB, uninitialized variable. I haven't seen this error for a while, it got fixed a while back. Don't ask me which commit though :)

Comment 17 Alexey Kuznetsov 2009-10-31 07:25:40 UTC
Problem still here. Now i switched to Fedora 12 (rawhide version) with last X server. Old problem persist, but with other symptoms.

Layout options only affect on xserver, and window manager. I able to switch windows by my new Alt key (old super). But i unable to use new Alt to switch keyboard layout. So, new mapping ignored by keyboard switcher (guy who added through gnome pannel, as "add to panel" command)

xmodmap changes, recognized only by xev utitlity. keymodifiers ( i change my right super to right alt) wont accepted by application. So, i unable to use Right Alt+Left key in firefox to switch backward link.
Comment 18 Alexey Kuznetsov 2009-11-01 07:21:45 UTC
(In reply to comment #17)

my previous comment indicates some duplicate of keymodifiers in x-server system. xserver use one keymodifers map, application use other. can some one confirm it?
Comment 19 Alexey Kuznetsov 2009-11-01 07:23:19 UTC
*** Bug 17755 has been marked as a duplicate of this bug. ***
Comment 20 Daniel Stone 2011-05-31 15:16:10 UTC
Hi,
Sorry for the delay on answering this one.

So, as far as I can tell, there are three disparate bugs here:
    * Spurious BadAlloc error from xkbcomp about geometry: this is both completely harmless and already fixed upstream, so no problem. :)
    * Map Eject key to Print key but nothing happens: this is almost certainly a GNOME bug - it was buggy for a long time in this respect (although so was the X server, to be fair).  It was finally fixed about a year ago; can you confirm that this still occurs? The MappingNotify from xev indicates that another client does actually have that key grabbed.
    * xmodmap breaks with modifiers: unfortunately, I can't read Russian - can you or Sergey please translate?

Thanks.
Comment 21 Daniel Stone 2011-05-31 15:35:40 UTC
(In reply to comment #20)
>     * xmodmap breaks with modifiers: unfortunately, I can't read Russian - can
> you or Sergey please translate?

Actually, your blog doesn't appear to describe the problem with xmodmap at all.

Can you still reproduce this? If so, can you please provide more information (e.g. exact xmodmap recipe, expected result, actual result, output of `xkbcomp -xkb :0 -` from both before and after), as well as the X server version you're using?
Comment 22 Daniel Stone 2012-08-08 17:49:31 UTC
Assuming this one is fixed now.


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.