Bug 1657030 - keyboard layout is broken
Summary: keyboard layout is broken
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kwin
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Daniel Vrátil
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-06 21:41 UTC by Peter Hatina
Modified: 2019-11-07 06:09 UTC (History)
14 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2019-11-07 06:09:47 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
keymap dump (67.58 KB, text/plain)
2018-12-07 07:07 UTC, Peter Hatina
no flags Details

Description Peter Hatina 2018-12-06 21:41:46 UTC
Description of problem:

I am running KDE Plasma and try to add second keyboard layout next to default one (en US); for example slovak one.  Doing so, some key-combos stop working (alt+h which I am used to - switching between tmux panes).

Xev output:

KeyPress event, serial 40, synthetic NO, window 0x7e00001,
    root 0x14b, subw 0x7e00002, time 2809131, (60,43), root:(771,399),
    state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

FocusOut event, serial 40, synthetic NO, window 0x7e00001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 40, synthetic NO, window 0x7e00001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 40, synthetic NO, window 0x0,
    keys:  2   0   0   0   0   8   0   0   1   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

KeyRelease event, serial 40, synthetic NO, window 0x7e00001,
    root 0x14b, subw 0x7e00002, time 2809541, (60,43), root:(771,399),
    state 0x8, keycode 43 (keysym 0x68, h), same_screen YES,
    XLookupString gives 1 bytes: (68) "h"
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x7e00001,
    root 0x14b, subw 0x7e00002, time 2809882, (60,43), root:(771,399),
    state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False




Version-Release number of selected component (if applicable):
xkeyboard-config-2.21-3.fc27.noarch

How reproducible:
Always

Steps to Reproduce:
1. Add second keyboard layout in KDE Plasma Settings
2. Observe Xev's output
3. See FocusIn/FocusOut events instead of proper reaction

or

1. setxkbmap -layout sk
2. as above

Actual results:
alt+h is not sent

Expected results:
alt+h works

Comment 1 Peter Hutterer 2018-12-06 23:28:07 UTC
what's the output of setxkbmap -print after you set the layout, and I'll need the keymap from: xkbcomp -xkb $DISPLAY keymap.xkb

Comment 2 Peter Hatina 2018-12-07 07:06:30 UTC
$ setxkbmap -print
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us+sk:2+inet(evdev)+group(alt_shift_toggle)+capslock(ctrl_modifier)"	};
	xkb_geometry  { include "pc(pc104)"	};
};

keymap.xkb is rather long and is attached to this report.

Thanks.

Comment 3 Peter Hatina 2018-12-07 07:07:09 UTC
Created attachment 1512403 [details]
keymap dump

Comment 4 Peter Hutterer 2018-12-12 04:33:07 UTC
can't see anything obviously wrong with the keymap but the xev output shows something:


KeyPress event, serial 40, synthetic NO, window 0x7e00001,
    root 0x14b, subw 0x7e00002, time 2809131, (60,43), root:(771,399),
    state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

alt key is now down

FocusOut event, serial 40, synthetic NO, window 0x7e00001,
    mode NotifyGrab, detail NotifyAncestor

something (probably the window manager) grabbed the device

FocusIn event, serial 40, synthetic NO, window 0x7e00001,
    mode NotifyUngrab, detail NotifyAncestor

something (probably the WM) ungrabbed the device



KeyRelease event, serial 40, synthetic NO, window 0x7e00001,
    root 0x14b, subw 0x7e00002, time 2809541, (60,43), root:(771,399),
    state 0x8, keycode 43 (keysym 0x68, h), same_screen YES,
    XLookupString gives 1 bytes: (68) "h"
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x7e00001,
    root 0x14b, subw 0x7e00002, time 2809882, (60,43), root:(771,399),
    state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False


releases for h and alt. 

So the key press for h is missing. My first guess would be that kwin doesn't call XAllowEvents with the correct parameters so the event is dropped rather than replayed. Is this under Wayland or under Xorg? Can you reproduce this in a GNOME session?

Comment 5 Peter Hatina 2018-12-17 19:49:48 UTC
Hi,

running KDE Plasma, the "h" key press event is missing. When I switched to GNOME Shell, it worked as expected.

I am using sddm login manager and choose from the combobox either Plasma or GNOME Shell on Xorg.

Any tips?

Comment 6 Peter Hutterer 2018-12-18 05:38:56 UTC
Definitely a kde window manager bug then, punting to kwin in the hope it's the right component.

Comment 7 Ben Cotton 2019-10-31 20:17:54 UTC
This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 8 Peter Hatina 2019-11-07 06:09:47 UTC
Upgrading to KDE Plasma 5.17 seems to fix this.  Closing.


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