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 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)
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.py
PS: 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;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
- Finally, 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)
xevshows the keyboard event. I am simply shocked, if I try to imagine what could be going in the mind of the people "inventing" such a change so simply.