X：使用 xrandr 关闭并再次打开显示器后，alt/ctrl/f1 不再起作用

Question

这是一个扩展评论，而不是答案。

在我的系统中，Ctrl++Alt工作正常，我得到了和F1的 KeyPress 事件，但没有得到的KeyPress 事件。虽然我知道它可以工作，因为我已经转移到 tty1。controlaltF1

这是我的例子的完整xev输出（仅供比较）：

root@debi64:/home/gv/Desktop/PythonTests# xev -event keyboard
Outer window is 0x4400001, inner window is 0x4400002

KeymapNotify event, serial 18, synthetic NO, window 0x0,
    keys:  4294967192 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   0   0   0   0   

KeyPress event, serial 25, synthetic NO, window 0x4400001,
    root 0x281, subw 0x0, time 11550957, (157,186), root:(748,462),
    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 28, synthetic NO, window 0x4400001,
    root 0x281, subw 0x0, time 11550960, (157,186), root:(748,462),
    state 0x8, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x4400001,
    root 0x281, subw 0x0, time 11553775, (157,186), root:(748,462),
    state 0xc, keycode 67 (keysym 0x1008fe01, XF86Switch_VT_1), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x4400001,
    root 0x281, subw 0x0, time 11553902, (157,186), root:(748,462),
    state 0xc, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x4400001,
    root 0x281, subw 0x0, time 11553902, (157,186), root:(748,462),
    state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeymapNotify event, serial 28, synthetic NO, window 0x0,
    keys:  4294967169 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   0   0   0   0   

ClientMessage event, serial 28, synthetic YES, window 0x4400001,
    message_type 0x11b (WM_PROTOCOLS), format 32, message 0x119 (WM_DELETE_WINDOW)

我还创建了一个小的 python 脚本来模拟Ctrl+ alt+F1按键。当我运行脚本时，我也毫无问题地转移到 tty1 中。

您甚至可以尝试在您的计算机中运行此脚本，看看您是否进入 tty1，作为双重检查/验证您的键盘是否正常工作：

https://github.com/gevasiliou/PythonTests/blob/master/pykey-test.py

PS：除了脚本之外，您还可以尝试运行它，#chvt 1该命令也会将您转移到 tty1。

经过一些研究后，其他用户报告说，由于 xserver 更新（显然），++Ctrl键已停止工作，这修改了 tty 中应用的一些分辨率设置。altfn

例如在这篇文章中，通过在启动期间应用特定的 vga 分辨率作为内核参数 (vga=mode)，如 vga=0x0362，该问题已得到解决。显然，这些系统更新之一搞乱了那些人的解决方案，所以也许这也是你的情况（只有上帝知道为什么）。

PS：要查看系统支持的可用模式，您需要运行hwinfo --framebuffer | grep 'Mode'并从列出的模式中选择一种模式。

顺便说一句，您F3在问题中包含了 xev with 的某些部分，但是 with 的输出是什么F1？

更新：
作为进一步的故障排除，可能值得尝试以下一些方法：

看着xrandr 源代码看来 --off 选项执行以下命令：

set_name_xid (&config_output->mode, None);
set_name_xid (&config_output->crtc, None);
config_output->changes |= changes_mode | changes_crtc;

您可以尝试通过指定 --mode 和 --crtc xrandr 选项而不是 --auto 来重新启用 --output（以防 xrandr“自动化”无法正常工作）。

在这个关于控制台的内核文档，您可以看到目录下的虚拟控制台操作的驱动程序/支持的模块有哪些 /sys/class/vtconsole。
您可以比较开机期间和关机后所有文件/模块的值，您有不同的行为。也许某些东西正在关闭时间内修改这些值。

这是我的系统的打印输出，其中切换到 tty1-2-3-4-5-6 工作正常：

root@debi64:/home/gv/Desktop/PythonTests# for f in $(find /sys/class/vtconsole/vtcon0/ -type f);do echo -e "File : $f \c\c\c";echo -e "-VALUE : \c";cat $f;done
File : /sys/class/vtconsole/vtcon0/bind -VALUE : 0
File : /sys/class/vtconsole/vtcon0/power/runtime_active_kids -VALUE : 0
File : /sys/class/vtconsole/vtcon0/power/runtime_suspended_time -VALUE : 0
File : /sys/class/vtconsole/vtcon0/power/autosuspend_delay_ms -VALUE : cat: /sys/class/vtconsole/vtcon0/power/autosuspend_delay_ms: Input/output error
File : /sys/class/vtconsole/vtcon0/power/runtime_enabled -VALUE : disabled
File : /sys/class/vtconsole/vtcon0/power/runtime_active_time -VALUE : 0
File : /sys/class/vtconsole/vtcon0/power/control -VALUE : auto
File : /sys/class/vtconsole/vtcon0/power/async -VALUE : disabled
File : /sys/class/vtconsole/vtcon0/power/runtime_usage -VALUE : 0
File : /sys/class/vtconsole/vtcon0/power/runtime_status -VALUE : unsupported
File : /sys/class/vtconsole/vtcon0/uevent -VALUE : 
File : /sys/class/vtconsole/vtcon0/name -VALUE : (S) VGA+
root@debi64:/home/gv/Desktop/PythonTests# for f in $(find /sys/class/vtconsole/vtcon1/ -type f);do echo -e "File : $f \c\c\c";echo -e "-VALUE : \c";cat $f;done
File : /sys/class/vtconsole/vtcon1/bind -VALUE : 1
File : /sys/class/vtconsole/vtcon1/power/runtime_active_kids -VALUE : 0
File : /sys/class/vtconsole/vtcon1/power/runtime_suspended_time -VALUE : 0
File : /sys/class/vtconsole/vtcon1/power/autosuspend_delay_ms -VALUE : cat: /sys/class/vtconsole/vtcon1/power/autosuspend_delay_ms: Input/output error
File : /sys/class/vtconsole/vtcon1/power/runtime_enabled -VALUE : disabled
File : /sys/class/vtconsole/vtcon1/power/runtime_active_time -VALUE : 0
File : /sys/class/vtconsole/vtcon1/power/control -VALUE : auto
File : /sys/class/vtconsole/vtcon1/power/async -VALUE : disabled
File : /sys/class/vtconsole/vtcon1/power/runtime_usage -VALUE : 0
File : /sys/class/vtconsole/vtcon1/power/runtime_status -VALUE : unsupported
File : /sys/class/vtconsole/vtcon1/uevent -VALUE : 
File : /sys/class/vtconsole/vtcon1/name -VALUE : (M) frame buffer device

最后，可能值得研究一下 Xserver 等可能的自动节能功能DPMS可以在长时间不活动时自动激活的设置。

第二次更新：

环顾四周，我发现虚拟终端上的 DPMS 和其他有用的省电相关设置可以通过setterm命令进行控制。如果您的虚拟终端似乎正在睡眠，您可以尝试通过向setterm --reset它们发送命令来唤醒它们（如果是这种情况）。要将命令从常规 tty7 发送到另一个 tty，您需要使用： setsid bash -c 'exec setterm --reset <> /dev/tty1 >&0 2>&1'
唯一的问题是您必须在 tty1 登录。

为了进行测试，您可以使用 setsid bash -c 'exec setterm --reverse on <> /dev/tty1 >&0 2>&1'tty1 工作时，如果您切换到它，chvt 1您可以观察结果（在终端中反向交换颜色 - 在 Debian 中测试并工作）。

setterm --powersave off此外，setterm 还为您提供了使用等方式启用/禁用省电的选项（请参阅man setterm）

Answer 1