Bug 766788 - Meta key does not work.
Summary: Meta key does not work.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: emacs
Version: 16
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Karel Klíč
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-12 15:55 UTC by john.haxby@oracle.com
Modified: 2013-03-03 23:03 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-09 15:58:00 UTC
Type: ---


Attachments (Terms of Use)
Possible patch (764 bytes, patch)
2011-12-20 11:02 UTC, john.haxby@oracle.com
no flags Details | Diff

Description john.haxby@oracle.com 2011-12-12 15:55:29 UTC
Description of problem:

I use KDE and have set up xkb so that the Alt keys send Alt and the Win keys send Meta.   When typing "Meta-x" (for example) in emacs I just get "x" instead of the expected behaviour: the Meta key is ignored.

xev shows that the four keys all transmit the right keysym:

KeyPress event, serial 190, synthetic NO, window 0x7200001,
    root 0xb6, subw 0x0, time 26219164, (149,45), root:(1649,480),
    state 0x0, keycode 133 (keysym 0xffe7, Meta_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 190, synthetic NO, window 0x7200001,
    root 0xb6, subw 0x0, time 26248916, (2,41), root:(1502,476),
    state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 190, synthetic NO, window 0x7200001,
    root 0xb6, subw 0x0, time 26271820, (-2,88), root:(1498,523),
    state 0x0, keycode 108 (keysym 0xffea, Alt_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 190, synthetic NO, window 0x7200001,
    root 0xb6, subw 0x0, time 26293988, (-2,83), root:(1498,518),
    state 0x0, keycode 134 (keysym 0xffe8, Meta_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False


Version-Release number of selected component (if applicable):
   emacs-23.3-8.fc16.x86_64


How reproducible: Always


Steps to Reproduce:
1. Start up emacs in X mode
2. Ensure (using xev) that the Win keys send meta
3. Hit "Meta" and "x" together in emacs
  
Actual results:
  An "x" is inserted in the current buffer


Expected results:
  The ":" prompt should be display for [(meta) x]

Additional info:

Comment 1 john.haxby@oracle.com 2011-12-20 11:02:41 UTC
Created attachment 548818 [details]
Possible patch

I believe this patch fixes the problem correctly.   It seems that previously GTK didn't call XFilterEvent for KeyPress and KeyRelease events and now it does and calling it again simply clears the Meta modifier.

Comment 2 john.haxby@oracle.com 2011-12-20 13:52:04 UTC
Alas, that patch breaks Multi_key.   It looks as though XFilterEvent is filtering the Meta keys which suggests that there is a bug elsewhere, probably in ibus.

Comment 3 john.haxby@oracle.com 2012-01-09 15:58:00 UTC
This was fixed.   Unfortunately I don't know what by.   There were changes to various kde, qt, m17n, etc that might have some effect.   Anyway, for anyone seeing this behaviour, updating things seems to fix the behaviour


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