방금 Linux Mint 18.1 KDE(Plasma 5.8.5, Qt 5.6.1)로 업그레이드했는데 이전에 겪어보지 못한 이상한 문제를 제외하면 모든 것이 잘 돌아가고 있습니다. X 창 수준에서 내 "Ctrl+s" 시퀀스가 응용 프로그램 수준에 도달하지 못하기 때문에 무언가를 포착하고 있습니다. 예를 들어, "Ctrl+s"나 "Ctrl+x Ctrl+s" 표준 emacs 키는 작동하지 않습니다. 보다 일반적인 KDE 프로그램에서도 "Ctrl+s" 순서가 깨졌습니다. 나는 이것이 KDE 프레임워크일 수도 있다고 생각하지만 Ctrl+s에 대해 정의된 전역 단축키가 없습니다(전역 Ctrl+s를 Ctrl+Shift+s로 옮겼습니다)
이것은 벨소리입니다. "Ctrl+s" 시퀀스만 종료되었습니다. 내가 아는 한, 다른 모든 키는 예상대로 작동합니다.
실행을 통해 무슨 일이 일어나고 있는지에 대한 몇 가지 단서를 얻을 수 있습니다 xev
. Ctrl+s를 입력하면 다음 시퀀스가 생성됩니다.
KeyPress event, serial 40, synthetic NO, window 0x3400001,
root 0x4c4, subw 0x0, time 14783934, (-711,685), root:(1159,750),
state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
FocusOut event, serial 40, synthetic NO, window 0x3400001,
mode NotifyGrab, detail NotifyAncestor
FocusIn event, serial 40, synthetic NO, window 0x3400001,
mode NotifyUngrab, detail NotifyAncestor
KeymapNotify event, serial 40, synthetic NO, window 0x0,
keys: 2 0 0 0 4294967200 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
KeyRelease event, serial 40, synthetic NO, window 0x3400001,
root 0x4c4, subw 0x0, time 14784998, (-711,685), root:(1159,750),
state 0x4, keycode 39 (keysym 0x73, s), same_screen YES,
XLookupString gives 1 bytes: (13) ""
XFilterEvent returns: False
KeyRelease event, serial 40, synthetic NO, window 0x3400001,
root 0x4c4, subw 0x0, time 14785566, (-711,685), root:(1159,750),
state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
이는 Ctrl+y와 같은 키를 누르는 것과는 완전히 다릅니다. Ctrl+s 시퀀스는 핵심 문제인 "FocusOut" 및 "FocusIn"을 생성합니다. 이는 일부 프로세스(아마도 KDE 창 관리자)가 시퀀스를 가져오고 있음을 나타냅니다. 그러나 나는 어떤 프로세스가 열쇠를 쥐고 있는지 결정할 수 없습니다.
내 이론은 showkey -a
이것을 터미널에서 실행하여 확인되었습니다. 이는 응용 프로그램 수준이 Ctrl+s를 수신하지 않는다는 것을 명확하게 확인합니다. 예를 들어, 다른 모든 Ctrl+는 키코드를 제공합니다.
^Y 25 0031 0x19
^R 18 0022 0x12
^T 20 0024 0x14
^T 20 0024 0x14
그러나 Ctrl+s를 입력하려고 하면 아무 일도 일어나지 않습니다.
추가적으로 저는 KDE에서 Ctrl+s에 매핑된 전역 단축키가 없고 Ctrl+s가 실제로 아무 것도 하지 않는다는 것을 두 번(세 번) 확인했습니다. /dev/null로 직접 전송되는 것 같습니다...
나도 시도했다
xdotool keydown Ctrl+s;xdotool key XF86LogGrabInfo; xdotool keyup Ctrl+s;
어떤 프로세스가 Ctrl+s 키를 잡고 있는지 확인할 수 있는지 확인하세요. 그러나 로그에서는 그러한 프로세스를 식별할 수 없습니다.
누군가가 다음에 어디로 가야할지 알기를 바라면서 아이디어가 고갈되기 시작했습니다.
답변1
Xorg.0.log
더 자세한 분석을 보면 이 프로세스가 Ctrl+s
Wayland/KDE 전역 단축키 관리자 프로세스에서 사용되는 것으로 나타났습니다.kglobalaccel5
그러나 전역 단축키로 정의된 키가 없다는 것을 알고 있기 때문에 Ctrl+s
유일한 해결책은 이것이 키 매핑 충돌(또는 오히려 키 코드 충돌)이라는 것입니다.
(몇 가지 시행착오 테스트를 거친 후) 내 키보드에서 생성된 키 이벤트가 ("대시보드 위젯"을 열기 위해 매핑한) 이벤트와 Ctrl+§
동일하다는 것이 밝혀졌습니다.Ctrl+s
Ctrl+§
아마도 "rapoo" 빠른 타이핑 키보드에 특정한 키맵이 아닌 일반 키맵을 사용하고 있기 때문일 가능성이 높습니다. 키와 수정자 상호 작용이 어떻게 이러한 충돌을 일으킬 수 있는지에 대한 자세한 지식이 없습니다. 일반 키(예: "s" 및 "§")는 단독으로 작동하지만 "Ctrl" 수정자와 함께 사용하면 동일한 코드 값을 제공합니다.
해결책은 전역 매핑을 제거하는 것입니다.Ctrl+§
흥미로운 질문입니다!