Alt+Printscreen 停止工作，如何查找监听事件的进程

Question

今天很奇怪的问题。我打算发布一个关于另一个问题的帖子，并想截取终端窗口的屏幕截图。我准备好了一切，点击Alt+ Printscreen，什么也没发生。

我进入了键盘快捷键，看看重新定义快捷键是否有效。它做了。我试图将它设置回Alt+Printscreen但窗口只是坐在那里听按键。就好像我从未按下过钥匙一样。

无论是Alt和Printscreen按键独立工作就好了......我也试着看的输出xev，我按下键。它会听到 Alt 按下但之后没有听到 Printscreen。

我已经在 Compiz 和普通的 metacity 中尝试过这个。我还有一个备用键盘，它显示相同的行为（一个键盘是 PS/2，备用是 USB - 所以不是端口问题）。

就好像事件链中有什么东西在事件上吐口水，这样其他人就听不到了。我的问题基本上是：如何找到响应某些事件的进程？

按照要求：

oli@bert:~$ xmodmap -pke | grep -i mode
keycode  82 = KP_Subtract XF86_Prev_VMode KP_Subtract XF86_Prev_VMode
keycode  86 = KP_Add XF86_Next_VMode KP_Add XF86_Next_VMode
keycode 100 = Henkan_Mode NoSymbol Henkan_Mode
keycode 203 = Mode_switch NoSymbol Mode_switch

和

oli@bert:~$ xmodmap -pke | grep -i print
keycode 107 = Print Sys_Req Print Sys_Req
keycode 218 = Print NoSymbol Print

编辑：当我发布这篇文章时，我在 Lucid 上使用自制的 2.6.35 内核。事实证明我的问题与内核有关，而不是 X。

某个地方的某个人已经决定 alt-printscreen 应该呈现一个 SysRq 事件。从技术上讲，也许应该这样做，但这打破了十多年来 Linux 和 Windows 的“已知行为”。

Answer 1

根据我的编辑，这似乎直接链接到内核版本 2.6.35（可能还有后续内核），其中 alt+prscr 呈现 sysrq 事件。

SysRq 似乎无法绑定（至少从我的胡说八道）但您可以通过将以下内容添加到以下来禁用愚蠢的新行为/etc/sysctl.conf：

kernel.sysrq = 0