What happens when Ctrl + Alt + F<Num> is pressed?

It is the kernel. Keep in mind the keyboard is hardware and everything that happens there passes through the kernel; in the case of VT switching, it handles the event completely itself and does not pass anything on to userspace (however, I believe there is an ioctl related means by which userspace programs can be notified of a switch occurring involving them and perhaps affect it, which X no doubt does).

The kernel has a keymap build into it; this can be modified while running with loadkeys, and viewed with dumpkeys:

[...] keycode 59 = F1 F13 Console_13 F25 alt keycode 59 = Console_1 control alt keycode 59 = Console_1 keycode 60 = F2 F14 Console_14 F26 alt keycode 60 = Console_2 control alt keycode 60 = Console_2 keycode 61 = F3 F15 Console_15 F27 alt keycode 61 = Console_3 control alt keycode 61 = Console_3 [...] 

The kernel source contains a default keymap file which looks exactly like this; for 3.12.2 it's src/drivers/tty/vt/defkeymap.map. You'll also notice there is a corresponding defkeymap.c file (this can be generated with loadkeys --mktable). The handling is in keyboard.c (all these files are in the same directory) which calls set_console() from vt.c:

» grep set_console *.c keyboard.c: set_console(last_console); keyboard.c: set_console(i); keyboard.c: set_console(i); keyboard.c: set_console(value); vt.c:int set_console(int nr) vt_ioctl.c: set_console(arg); 

I edited some hits out of that list; you can see the function signature on the second last line.

So these are the things involved in the switching. If you look at the sequence of calls, eventually you come back to kbd_event() in keyboard.c. This is registered as an event handler for the module:

(3.12.2 drivers/tty/vt/keyboard.c line 1473)

MODULE_DEVICE_TABLE(input, kbd_ids); static struct input_handler kbd_handler = { .event = kbd_event, <--- function pointer HERE .match = kbd_match, .connect = kbd_connect, .disconnect = kbd_disconnect, .start = kbd_start, .name = "kbd", .id_table = kbd_ids, }; int __init kbd_init(void) { [...] error = input_register_handler(&kbd_handler); 

Hence, kbd_event() should be called when something bubbles up from the actual hardware driver (probably something from drivers/hid/ or drivers/input/). However, you won't see it referred to as kbd_event outside of that file, since it is registered via a function pointer.

Some resources for scrutinizing the kernel

• The Linux Cross Reference Identifier Search is a great tool.
• The Interactive Linux Kernel Map is an interesting graphical front end to the cross reference tool.
• There are a few historical archives of the massive Linux Kernel Mailing List (LKML), which goes back to at least 1995; some of them are not maintained and have broken search features, but the gmane one seems to work very well. People have asked a lot of questions on the mail list and it is a primary means of communication amongst the developers as well.
• You can inject your own printk lines into the source as a simple means of tracing (not all of the standard C lib can be used in kernel code, including printf from stdio). printk stuff ends up in syslog.

Wolfgang Mauerer wrote a great big book on the 2.6 kernel, Professional Linux Kernel Architecture, which goes through a lot of the source. Greg Kroah-Hartman, one of the principle devs for the last decade, also has a lot of things kicking around.