在fedora37 / gnome 43 系统中关于快捷键设置的一个坑-凯发app官方网站

本人平时喜欢尽可能少让双手离开键盘，鼠标越少用越好。所以对系统的快捷键设置的比较多。
{banned}最佳近遇到一个奇怪的事情，在xterm里面使用转义序列（escape sequence）自定义了一组按键。
shift alt h等等，其他按键都很好，唯独这个shift alt h有问题。
翻边了所有快捷键配制，没有发现有其他快捷键设置为一样而冲突的情况，但这个按键就是不生效。
在全网搜索也没有发现有同样问题的人，但有个国外的老兄给了个思路和方法。使用下面的命令可以查看该按键是否激活了某个grab？

命令如下：
sleep 3; xdotool key "xf86loggrabinfo"

在sleep的3秒钟，一直按住shift alt h，直到命令结束。然后查看xorg的日志文件。
vim /var/log/xorg.1.log

37099 [ 15073.067] end list of registered passive grabs
37100 [ 15305.682] (ii) printing all currently active device grabs:
37101 [ 15305.682] active grab 0x4022a0e7 (xi2) on device 'virtual core keyboard' (3):
37102 [ 15305.682] client pid 2229 /usr/bin/gnome-shell
37103 [ 15305.682] at 15303526 (from passive grab) (device thawed, state 1)
37104 [ 15305.682] xi2 event mask for device 3: 0xc000
37105 [ 15305.682] passive grab type 2, detail 0x2b, activating key 43
37106 [ 15305.682] owner-events false, kb 0 ptr 1, confine 0, cursor 0x0
37107 [ 15305.682] (ii) end list of active device grabs

可以看到这个快捷键被gnome-shell给截获了。
又再次把系统的快捷键和extensions的快捷键翻了一边也没有发现冲突。
再次想起用xev看看情况。
keypress event, serial 37, synthetic no, window 0x3600001,
root 0x7a5, subw 0x0, time 13650386, (71,62), root:(109,169),
state 0x10, keycode 50 (keysym 0xffe1, shift_l), same_screen yes,
xlookupstring gives 0 bytes:
xmblookupstring gives 0 bytes:
xfilterevent returns: false

keypress event, serial 37, synthetic no, window 0x3600001,
root 0x7a5, subw 0x0, time 13651791, (71,62), root:(109,169),
state 0x11, keycode 64 (keysym 0xffe7, meta_l), same_screen yes,
xlookupstring gives 0 bytes:
xmblookupstring gives 0 bytes:
xfilterevent returns: false

focusout event, serial 37, synthetic no, window 0x3600001,
mode notifygrab, detail notifyancestor

focusout event, serial 37, synthetic no, window 0x3600001,
mode notifyungrab, detail notifypointer

focusin event, serial 37, synthetic no, window 0x3600001,
mode notifyungrab, detail notifyancestor

keymapnotify event, serial 37, synthetic no, window 0x0,
keys: 4294967229 0 0 0 0 0 4 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 37, synthetic no, window 0x3600001,
root 0x7a5, subw 0x0, time 13654827, (71,62), root:(109,169),
state 0x19, keycode 64 (keysym 0xffe7, meta_l), same_screen yes,
xlookupstring gives 0 bytes:
xfilterevent returns: false

keyrelease event, serial 37, synthetic no, window 0x3600001,
root 0x7a5, subw 0x0, time 13654889, (71,62), root:(109,169),
state 0x11, keycode 50 (keysym 0xffe1, shift_l), same_screen yes,
xlookupstring gives 0 bytes:
xfilterevent returns: false

上面是所有从按下shift，然后alt，然后h各阶段发出的事件，可以看到按了h后，有两个focusout和一个focusin，说明这个按键真的被grab了，但没有更多其他信息。keymapnotify event里面的信息网上也没找到任何明确的说法。
在实在没有任何头绪的时候，就把所有的按键全部都按了一遍。
你别说，你还真别说。还真被试出了规律。
我在系统中设置了很多个alt 快捷键来执行各种常用工具，比如alt h就是切换到chrome。

经过测试发现，所有被我设置过的alt 的所对应的shift alt 都不能被xterm接收到。

这就是说在系统设置快捷键时，虽然我设置的是alt ，但实际上系统把包含其他的modifier的情况也算进去了。但在遍历完所有注册的快捷键，在全部都没有匹配上的情况下并没有重新丢给当前窗口。

后面还发现了一个现象，如果把大写打开，xterm就能够接收到shift alt h了，也算是一种解决方法，毕竟这个组合使用的频率很低。

{banned}最佳后下载了gnome-shell的源码，也没有找到明确的说法，以后再说吧。

一些使用过的命令，放在这里，算是个记录吧
sleep 3; xdotool key "xf86loggrabinfo"
xkbcomp -xkb $display active_map.txt
vi /usr/include/x11/keysymdef.h
xinput list
gsettings list-recursively | grep ''alt"
setxkbmap -print -verbose 10

阅读(1435) | 评论(0) | 转发(0) |

上一篇：在xterm和tmux中允许从本地或者远程ssh拷贝字符到系统剪贴板的功能

下一篇：lolcat ：一个更加有趣（彩色）的cat命令

给主人留下些什么吧！~~

| | | | |

感谢所有关心和支持过chinaunix的朋友们