4

(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: False

But 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 xf86switch
keycode  67 = F1 F1 F1 F1 F1 F1 XF86Switch_VT_1 F1 F1 XF86Switch_VT_1
keycode  68 = F2 F2 F2 F2 F2 F2 XF86Switch_VT_2 F2 F2 XF86Switch_VT_2
keycode  69 = F3 F3 F3 F3 F3 F3 XF86Switch_VT_3 F3 F3 XF86Switch_VT_3
keycode  70 = F4 F4 F4 F4 F4 F4 XF86Switch_VT_4 F4 F4 XF86Switch_VT_4
keycode  71 = F5 F5 F5 F5 F5 F5 XF86Switch_VT_5 F5 F5 XF86Switch_VT_5
keycode  72 = F6 F6 F6 F6 F6 F6 XF86Switch_VT_6 F6 F6 XF86Switch_VT_6
keycode  73 = F7 F7 F7 F7 F7 F7 XF86Switch_VT_7 F7 F7 XF86Switch_VT_7
keycode  74 = F8 F8 F8 F8 F8 F8 XF86Switch_VT_8 F8 F8 XF86Switch_VT_8
keycode  75 = F9 F9 F9 F9 F9 F9 XF86Switch_VT_9 F9 F9 XF86Switch_VT_9
keycode  76 = F10 F10 F10 F10 F10 F10 XF86Switch_VT_10 F10 F10 XF86Switch_VT_10
keycode  95 = F11 F11 F11 F11 F11 F11 XF86Switch_VT_11 F11 F11 XF86Switch_VT_11
keycode  96 = F12 F12 F12 F12 F12 F12 XF86Switch_VT_12 F12 F12 XF86Switch_VT_12

The 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.

  • Are you sure the first console isn’t where the X server runs? Have you tried <ALT+CTRL+F2>? – phg Dec 5 '16 at 8:18
  • @phg Yes, 1: lsof -p shows its tty, 2: I tried alt/ctrl/f2 and it doesn't work. X have some option for that, but I won't override the default X config of my distribution. Here I can read xorg.conf has a DontVTSwitch ServerFlag for this wonderful feature; I suspect my distro enables it by default to make the life of its users nicer. I want to set it back to its normal (false) state, but without the need to override my autogenerated, hardcoded xorg.conf in /usr/share), and without the need of the restart of my running apps. – peterh Dec 5 '16 at 8:28
  • It works normally on Mint 18 Cinnamon. What Mint do you have? – AlexP Dec 5 '16 at 8:55
  • @AlexP Latest mint stable. It also worked by me. After that, I worked a lot, dist-upgraded a lot, and somehow now doesn't work. My keyboard is OK, xev shows 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. – peterh Dec 5 '16 at 8:57
  • 1
    Is there an application / window manager / desktop manager running which may have hijacked Ctrl-Alt-Fn as some sort of hotkeys? – AlexP Dec 5 '16 at 9:00
2
+100

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:

  1. 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).

  1. 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
  1. 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)

  • Thanks! I tried f1, f3, etc, I make the question consistent. I also tried the python code (+ installed the PyKeyboard python module for that). It doesn't switch, it prints only a "H": $ ./pp Lets start - A Key will be typed in terminal now just for testing. key tapped Control Alt F1 will be pressed now H – peterh Dec 9 '16 at 12:28
  • Strange! In my machine it just switches to tty1. What about if you run chvt 1 or 2 or 3, etc? – George Vasiliou Dec 9 '16 at 12:30
  • chvt is quite funny! As user gives error: Couldn't get a file descriptor referring to the console. As root: it makes the display black for around 0.2s, then it hangs until ctrl/c. Stracing it shows that it waits in an ioctl(3, VT_WAITACTIVE, 0x3) = -1 EINTR (Interrupted system call) syscall. (The EINTR was caused by my ctrl/c.) The relevant strace lines: ioctl(3, TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(3, KDGKBTYPE, 0x7fff0b6a2767) = 0 ioctl(3, VT_ACTIVATE, 0x3) = 0 ioctl(3, VT_WAITACTIVE, 0x3) = -1 EINTR – peterh Dec 9 '16 at 12:36
  • Also is this file cat /etc/default/console-setup do you have the line ACTIVE_CONSOLES="/dev/tty[1-6]" before and after xrandr --off thing? – George Vasiliou Dec 9 '16 at 12:38
  • Yes, consoles are active, it is in the common linux setting (tty1-tty6 active with a /bin/login from systemd, tty7 has some system log, on tty8 is the X). I can check them with a cat /dev/vcs[1-6], they are ok. – peterh Dec 9 '16 at 12:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.