(After editing significant new infos into the question)After turning a display off from command line (xrandr --output ... --off), and then turning it back (xrandr --output ... --auto), my X desktop loses the capability to switch to a character console (i.e. alt/ctrl/f1 doesn't work any more).Other X controlling shortcuts (alt/ctrl/backspace) still work.Why? How to re-enable this feature?Info: it is Linux Mint, latest stable. The problems happens explicitly after I switched the X off with an xrandr --output ... --off from command line, and then turned it on next morning again (with an xrandr --output ... --auto command).I use this, because I need to completely turn it off before I go home and the normal settings (energy settings somewhere in the control panel) aren't enough or buggy.My keyboard is okay, for example, xev shows the alt/ctrl/f3 release event correctly:KeyRelease event, serial 37, synthetic NO, window 0x3c00001,    root 0x2e1, subw 0x0, time 1622285717, (99,77), root:(961,532),    state 0xc, keycode 69 (keysym 0x1008fe03, XF86Switch_VT_3), same_screen YES,    XLookupString gives 0 bytes:     XFilterEvent returns: FalseBut the keypress event is not in the list. Thus, xev can't see the press of alt/ctrl/f3, but somehow it can see its release.Debug output:$ xmodmap -pke|grep -i xf86switchkeycode  67 = F1 F1 F1 F1 F1 F1 XF86Switch_VT_1 F1 F1 XF86Switch_VT_1keycode  68 = F2 F2 F2 F2 F2 F2 XF86Switch_VT_2 F2 F2 XF86Switch_VT_2keycode  69 = F3 F3 F3 F3 F3 F3 XF86Switch_VT_3 F3 F3 XF86Switch_VT_3keycode  70 = F4 F4 F4 F4 F4 F4 XF86Switch_VT_4 F4 F4 XF86Switch_VT_4keycode  71 = F5 F5 F5 F5 F5 F5 XF86Switch_VT_5 F5 F5 XF86Switch_VT_5keycode  72 = F6 F6 F6 F6 F6 F6 XF86Switch_VT_6 F6 F6 XF86Switch_VT_6keycode  73 = F7 F7 F7 F7 F7 F7 XF86Switch_VT_7 F7 F7 XF86Switch_VT_7keycode  74 = F8 F8 F8 F8 F8 F8 XF86Switch_VT_8 F8 F8 XF86Switch_VT_8keycode  75 = F9 F9 F9 F9 F9 F9 XF86Switch_VT_9 F9 F9 XF86Switch_VT_9keycode  76 = F10 F10 F10 F10 F10 F10 XF86Switch_VT_10 F10 F10 XF86Switch_VT_10keycode  95 = F11 F11 F11 F11 F11 F11 XF86Switch_VT_11 F11 F11 XF86Switch_VT_11keycode  96 = F12 F12 F12 F12 F12 F12 XF86Switch_VT_12 F12 F12 XF86Switch_VT_12The command xmodmap -pke | grep ' F[0-9]\+' gives exactly the same result.Additional info: the capability to switch to character console was lost on power off, and not on power on (thus, I had to ssh into my workstation from my mobile to enter the xrandr --output ... --auto command).Scripting test: I've tried @GeorgeVasilou 's script, what emulates the keyboard hits by injecting X11 event. The result is negative, the emulated alt/ctrl/f1 sequence appears only as a single H.
X: alt/ctrl/f1 doesn't work any more after turning the display off and on again with xrandr
x11;xorg;console;xrandr;virtual consoles
This is an extended comment and not an answer.In my system, in which Ctrl+Alt+F1 works correctly, I get a KeyPress event for control and alt, but not for F1. Though I know it works since I'm transfered to tty1. This is the complete xev output in my case (just for comparison):root@debi64:/home/gv/Desktop/PythonTests# xev -event keyboardOuter window is 0x4400001, inner window is 0x4400002KeymapNotify 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: FalseKeyPress 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: FalseKeyRelease 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: FalseKeyRelease 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: FalseKeyRelease 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: FalseKeymapNotify 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)I also created a small python script that simulates the Ctrl+alt+F1 key press. When I run the script, I'm also transferred in tty1 without problem.You could even try to run this script in your machine to see if you go or not at tty1, as a double check / verification that your keyboard works ok: https://github.com/gevasiliou/PythonTests/blob/master/pykey-test.pyPS: Instead of script, you could also try to run #chvt 1 that should transfer you also to tty1.After some research it has been reported by other users that Ctrl+alt+fn keys have stopped working due to xserver updates (obviously), which modified some resolution settings that apply in tty's.For example in this post, the problem has been solved by applying a specific vga resolution during boot as a kernel parameter (vga=mode), like vga=0x0362. Obviously one of those system updates messed up resolutions in those guys, so maybe this is also your case (and only god knows why).PS: To see available supported modes for your system you need to run hwinfo --framebuffer | grep 'Mode' and to select a mode from the ones that will be listed.By the way, you have included some part of xev with F3 in your question, but what is the output with F1?UPDATE:As a further troubleshooting it could worth to try some of the following:Looking at xrandr source code it seems that the --off option executes the following commands:set_name_xid (&config_output->mode, None);set_name_xid (&config_output->crtc, None);config_output->changes |= changes_mode | changes_crtc;You could try to reenable the --output by specifying --mode and --crtc xrandr options instead of --auto (just in case that xrandr automation is not working correctly).In this kernel document about console,  you can see what are the drivers / supported modules for operation of virtual consoles under directory  /sys/class/vtconsole.You could compare values of all the files/modules during power on and after power off that you have a different behavior.Maybe something is modifying those values in the -off time.This is a printout of my system in which switch to tty1-2-3-4-5-6 works ok: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;doneFile : /sys/class/vtconsole/vtcon0/bind -VALUE : 0File : /sys/class/vtconsole/vtcon0/power/runtime_active_kids -VALUE : 0File : /sys/class/vtconsole/vtcon0/power/runtime_suspended_time -VALUE : 0File : /sys/class/vtconsole/vtcon0/power/autosuspend_delay_ms -VALUE : cat: /sys/class/vtconsole/vtcon0/power/autosuspend_delay_ms: Input/output errorFile : /sys/class/vtconsole/vtcon0/power/runtime_enabled -VALUE : disabledFile : /sys/class/vtconsole/vtcon0/power/runtime_active_time -VALUE : 0File : /sys/class/vtconsole/vtcon0/power/control -VALUE : autoFile : /sys/class/vtconsole/vtcon0/power/async -VALUE : disabledFile : /sys/class/vtconsole/vtcon0/power/runtime_usage -VALUE : 0File : /sys/class/vtconsole/vtcon0/power/runtime_status -VALUE : unsupportedFile : /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;doneFile : /sys/class/vtconsole/vtcon1/bind -VALUE : 1File : /sys/class/vtconsole/vtcon1/power/runtime_active_kids -VALUE : 0File : /sys/class/vtconsole/vtcon1/power/runtime_suspended_time -VALUE : 0File : /sys/class/vtconsole/vtcon1/power/autosuspend_delay_ms -VALUE : cat: /sys/class/vtconsole/vtcon1/power/autosuspend_delay_ms: Input/output errorFile : /sys/class/vtconsole/vtcon1/power/runtime_enabled -VALUE : disabledFile : /sys/class/vtconsole/vtcon1/power/runtime_active_time -VALUE : 0File : /sys/class/vtconsole/vtcon1/power/control -VALUE : autoFile : /sys/class/vtconsole/vtcon1/power/async -VALUE : disabledFile : /sys/class/vtconsole/vtcon1/power/runtime_usage -VALUE : 0File : /sys/class/vtconsole/vtcon1/power/runtime_status -VALUE : unsupportedFile : /sys/class/vtconsole/vtcon1/uevent -VALUE : File : /sys/class/vtconsole/vtcon1/name -VALUE : (M) frame buffer deviceFinally, could be worthwhile to investigate possible automatic power saving features like Xserver DPMS settings that could be automatically activated in long periods of inactivity.  Second Update: Looking around i found that DPMS and other usefull power save related setting on virtual terminals can be controlled with setterm command.In the case that your virtual terminals seems to be sleeping , you could try to wake them up (if this is the case) by sending a setterm --reset command to them. To send a command from your regular tty7 to another tty you need to use:setsid bash -c 'exec setterm --reset <> /dev/tty1 >&0 2>&1'The only problem is that you must be logged in at tty1.For testing you can use setsid bash -c 'exec setterm --reverse on <> /dev/tty1 >&0 2>&1' and while your tty1 is working if you switch to it with chvt 1 you can observe the results (reverse on swaps colors in terminal - tested and working in Debian).Moreover setterm gives you options to enable/disable powersave using setterm --powersave off, and many more (see man setterm)