Console IOCTLs Under Linux
Console IOCTLs can be very useful and powerful. These are the IOCTls that involve the console. They are the user interface to manipulation of the console. I am going to go over these console IOCTLs and give you examples of them. You can make some pretty powerful programs, whether they be general utilities or security programs, with these (such as Auto Console Switching and Console Access Protection). The structure of this article will be the name of the IOCTL, and then example source code to uses of the IOCTL. Now, I must warn you that the console IOCTLs are being replaced by POSIX functions. These IOCTLs are undocumented Linux internals and can be added or dropped without warning. I did not include all the console IOCTLs, but I included the ones that I though would be important or useful. The switch statement for each of these IOCTLs is in linux/drivers/char/vt.c. Other interesting code to look at would be (all in linux/drivers/char) conmakehash.c, console.c, consolemap.c, keyboard.c, tty_io.c, vc_screen.c, vga.c. Other interesting files (also in linux/drivers/char) are console_struct.h, consolemap.h, kbd_kern.h, vt_kern.h, and uni_hash.tbl. We are going to be using the IOCTLs defined in /usr/include/linux/kd.h, and /usr/include/linux/vt.h.
The function prototype for ioctl() as defined in /usr/include/sys/ioctl.h is:
int ioctl(int fd, int request, …)
Technically the ioctl function prototype uses ‘int d’ but I think ‘int fd’ is a lot clearer.
‘fd’ is the file descriptor of the console (/dev/tty), ‘request’ is the IOCTL we are requesting (such as KDGETLED), and ‘…’ is argp, the arguments we are passing to ioctl(). When getting values from ioctl() we use a pointer and when the function returns, the value will be stored in our argument. ioctl() is specified in /usr/include/sys/ioctl.h
We will now briefly describe the IOCTLs, the arguments it uses, and an example on how to use it where applicable.
KDGETLED:
This will return the current state of the LEDs. These lights on your keyboard that are on or off when something such as Caps Lock is on. Although you can turn the LEDs on or off with KDSETLED (described next) without affecting the Caps Lock, Numeric Lock, or Scroll Lock.
It places one of the following values (or a combination of them) into a pointer, that points to a long int:
Defined in: /usr/include/linux/kd.h
0x1 – LED_SCR, set when the Scroll Lock LED is on
0x2 – LED_NUM, set when the Numeric Lock LED is on
0x4 – LED_CAP, set when the Caps Lock LED is on
As I previously mentioned, it can return combinations (or the sum) of the LEDs turned on. For example, if the Numeric Lock and Caps Lock are both on, it will return 0x6 (0x2 + 0x4). So when no lights are on, it will return 0x0. This is also how you turn all the LEDs off as described next in KDSETLED.
Example txt here.
KDSETLED:
I will not go over the values that can be passed again (LED_CAP, LED_NUM, LED_SCR, etc.) again because I described them for KDGETLED. The argument to ioctl() is a long int (I don’t see why this is a long int considering it uses a value no higher than 7) with the number of the LED you want to set. If you want to set more than one LED, add the LED #’s you want set together (such as LED_NUM + LED_CAP). This DOES NOT turn, for example, Caps Lock on. This just turns the LED on the keyboard. To actually turn Caps Lock on use KDSKBLED.
Example txt here.
KDGKBLED:
This is exactly the same as KDGETLED, except rather than getting the state of the LEDs, it gets the state of the flags themselves. Meaning, whether the LED is on or off doesn’t matter, this returns the actual flags (if Caps Lock is on.. even if we turned off the LED with ioctl() and a KDSETLED request. The example in KDGETLED will work exactly the same except that this is getting the flags, rather than the states of the LEDs.
KDSKBLED:
This is exactly the same as KDSETLED except it sets the flags rather than the states of the LEDs. In other words, we can turn the Caps Lock LED off and use this which will turn Caps Lock on. Now everything will be in uppercase even though the LED light for Caps Lock isn’t on.
Example txt here.
KDGKBTYPE:
This will always return KB_101 (0x02), which is the standard keyboard. So I am not even going to explain this. Two other values defined are KB_84 (0x01) and KB_OTHER (0x03).
Defined in: /usr/include/linux/kd.h
0x1 – KB_84
0x2 – KB_101 (Standard/Default)
0x3 – KB_OTHER
KDGETMODE:
This returns the current console mode into the argument passed to ioctl() that is a pointer to a long int. The console is by default in text mode. The two modes you have are graphics and text mode.
Defined in: /usr/include/linux/kd.h
0x00 – KD_TEXT – Text Mode (Default)
0x01 – KD_GRAPHICS – Graphics Mode
There had been KD_TEXT0 and KD_TEXT1 but they are obsolete now.
Example txt here.
KDSETMODE:
This takes a long int that is either set to I assume that SVGAlib uses this IOCTL (even if another function calls it). The modes and definitions are specified above.
Example:
***** TEST IN GRAPHICS MODE *****
***** TEST IN GRAPHICS MODE *****
***** TEST IN GRAPHICS MODE *****
(test with code above)
KDMKTONE:
This will generate a tone, and the amount of clock cycles are passed as the argument to ioctl(). Note this is different from KIOCSOUND which is the sound generation.
Example txt here.
KIOCSOUND:
This and KDMKTONE both make sounds but they are in fact different. This has tones from 0-30000 (the sounds are 1193180/frequency), whereas KDMKTONE has higher values such as, the default beep you hear when you get Ctrl-G (the value is 125<<16 + 0x637), is 8,193,591 clock cycles. Example txt here.
GIO_FONT and GIO_FONTX:
These are both very similar except GIO_FONTX returns more. GIO_FONTX returns a struct consolefontdesc, and GIO_FONT only returns the font data in expanded form (which is the same as consolefontdesc’s chardata). The structure for consolefontdesc is:
struct consolefontdesc {
unsigned short charcount; /* characters in font (256 or 512) */
unsigned short charheight; /* scan lines per character (1-32) */
char *chardata; /* font data in expanded form (8192 bytes) */
}
Example txt here.
PIO_FONTRESET:
This resets the font to the default font. You would use this if you were playing with fonts (with PIO_FONT) and messed it up, you could then reset it with this. This is no longer implemented, and I just wrote something for this for historical purposes.
Example txt here.
KDGKBMODE:
This will get the current keyboard mode (raw mode, unicode, half raw, etc.). The argument passed to ioctl() is a pointer to a long int.
Possible modes are: raw, medium raw, Unicode, and xlate.
Defined in: /usr/include/linux/kd.h
0x00 – K_RAW
0x01 – K_XLATE (the default keyboard mode)
0x02 – K_MEDIUMRAW
0x03 – K_UNICODE
Example txt here.
KDSKBMODE:
This will get the current keyboard mode (raw mode, unicode, half raw, etc.). The argument passed to ioctl() is a long int. I stated the possible values in KDGKBMODE.
Example txt here.
KDGKBMETA:
This will get the meta key handling mode. The default meta key handling mode is the escape prefix.
Defined in: /usr/include/linux/kd.h
0x00 There is no meta key handling mode set.
0x03 K_METABIT (which is setting the high order bit)
0x04 K_ESCPREFIX (escape prefix)
I believe that 0x01 is also escape prefix, but I’m not sure. I get 0x01 returned from KDGKBMETA but it is not defined in /usr/include/linux/kd.h, and 0x01 is not returned in the switch statement linux/drivers/char/vt.c.
Example txt here.
KDSKBMETA:
This will set the meta key handling mode. The modes are the same as the ones mentioned right before this in KDGKBMETA.
Example txt here.
KDGKBENT:
Gets an entry from the key translation table. It converts the keycode to an action code). You pass a struct kbentry.
Defined in: /usr/include/linux/kd.h
struct kbentry {
u_char kb_table; /* Table number where the key map is. */
u_char kb_index; /* An index into the key map. */
u_short kb_value; /* Value returned in here. */
}
It uses key_maps[] defined in linux/drivers/char/defkeymap.c, which is are pointers to other keymaps (such as plain_map[], shift_map[], etc.) All the keycodes are u_short.
All the keys are greater than or equal to 0.
Here are the maximum values (defined in linux/drivers/char/defkeymap.c):
kb_index <= NR_KEYS (NR_KEYS == 128)
kb_table <= MAX_NR_KEYMAPS (MAX_NR_KEYMAPS == 256)
Example txt here.
KDSKBENT:
Sets an entry in the key translation table. You pass a struct kbentry. See the KDGKBENT above for the structure (defined in /usr/include/linux/kd.h).
I am not going to include one for this.. it would have bad results. You set the kb_table to a value as an index to the keymap, kb_index as an index into the keymap, and kb_value as the value you want to set it to. You do not pass this as a pointer (i.e. not as &kbent as seen above.
KDGKBDIACR:
This will print all the accented symbols (or characters). The argument passed to ioctl() is a pointer to a struct kbdiacrs.
Defined in: /usr/include/linux/kd.h
struct kbdiacrs {
unsigned int kb_cnt;
struct kbdiacr[256];
};
The structure kbdiacr is where the actual symbols and values are in (also defined in /usr/include/linux/kd.h:
struct kbdiacr {
u_char diacr;
u_char base;
u_char result;
}
Example txt here.
KDGETKEYCODE:
This one should be fairly obvious. It reads the keys from the kernel keycode entry. This converts the scan code to keycode. The argument to ioctl() is a struct kbkeycode.
Defined in: /usr/include/linux/kd.h
struct kbkeycode {
unsigned int scancode;
unsigned int keycode;
}
Example txt here.
KDSIGACCEPT:
This is basically the equivalent of signal(). I assume signal() calls this, as this is the way to accept signals from keyboard input. The argument passed to ioctl() is the signal number the process is willing to accept. The value is greater than 1, but less than N_SIG.
Example txt here.
Now that this is the first VT_* IOCTL, I want to mention we now include /usr/include/linux/vt.h, and not /usr/include/linux/kd.h anymore. I must also mention that the next two sets of IOCTLs are my favorite. VT_* and TIOCLINUX are fun IOCTLs and can be incredibly useful and powerful.
VT_OPENQRY:
This will return an int that is the first available console number. If tty1-tty6 were all opened consoles, it would return 7. This value will be greater than 1, but less than the maximum number of consoles (MAX_NR_CONSOLES), is currently 63 (in Linux 2.0.33).
Example txt here.
VT_GETSTATE:
This gets the state of the active VT. The argument passed to ioctl() is apointer to a struct vt_stat.
Defined in: /usr/include/linux/vt.h
struct vt_stat {
unsigned short v_active; /* active VT */
unsigned short v_signal; /* signal to send */
unsigned short v_state; /* vt bitmask */
}
Example txt here.
VT_GETMODE:
This will return the mode of the active VT. The argument to ioctl() is a pointer to a struct vt_mode.
Defined in: /usr/include/linux/vt.h
struct vt_mode {
char mode; /* vt mode */
char waitv; /* if set, hangs on write when not active */
short relsig; /* sig to raise on release request */
short acqsig; /* sig to raise on acquisition */
short frsig; /* unused (set to 0) */
}
Example txt here.
VT_SETMODE:
This will set the mode of the active VT. The argument to ioctl() is a struct vt_mode. In the current kernel (which is 2.0.33) you can not set the mode to VT_ACKACQ because it will return an invalid argument. I listed vt_mode structure right above in VT_GETMODE. If you turn VT_PROCESS on and then change VTs yourself, it will turn VT_PROCESS off, effectively putting it in VT_AUTO mode again.
VT_RELDISP:
This will release a display. The argument you pass to ioctl() is a int to the VT number (ttyX). You will call VT_DISALLOCATE after this. This will return EINVAL if the tty mode is not VT_PROCESS (which is where the process controls the switching).
VT_DISALLOCATE:
This deallocates the memory associated with VT. The argument passed to ioctl() is the VT to disallocate. This would be called after VT_RELDISP.
Example txt here.
VT_RESIZE:
Sets the size the kernel thinks the screensize is. The argument passed to ioctl() is a pointer a struct vt_sizes.
Defined in: /usr/include/linux/vt.h
struct vt_sizes {
ushort v_rows; /* Number of rows on screen. */
ushort v_cols; /* Number of columns on screen. */
ushort v_scrollsize; /* Not longer used. */
}
This does NOT change the video mode, only what the kernel’s idea of the screensize.
Example txt here.
VT_RESIZEX:
Sets the size the kernel thinks the screen size plus more. Notice this uses a different structure than VT_RESIZE. This includes a little bit more than VT_RESIZE does. The argument passed to ioctl() is a pointer a struct vt_consize.
Defined in: /usr/include/linux/vt.h
struct consize {
unsigned short v_rows; /* rows */
unsigned short v_cols; /* columns */
unsigned short v_vlin; /* video scan lines */
unsigned short v_clin; /* video font heigh (must be < 32) */
unsigned short v_vcol; /* video column number */
unsigned short v_ccol; /* video font width? */
}
I’m not sure what v_ccol is for.
Example:
VT_ACTIVATE:
This is what happens when you do a Alt-Fx, and it switches the VT. This can be incredible useful to be able to have a program change the VTs without having to do it manually.
Example txt here.
VT_WAITACTIVE:
This will sleep until you switch to the VT it is watching (or another program calls VT_SWITCH and switches, for example). When this occurs, ioctl() will return true.
Example txt here.
VT_LOCKSWITCH:
VT_UNLOCKSWITCH:
VT_LOCKSWITCH disables switching the console, and VT_UNLOCKSWITCH disables locking and allows switching.
Example txt here.
VT_SENDSIG:
This is in the include file, but it isn’t used linux/drivers/char anywhere. This is to send a signal to the bitmask of a VT. Because it isn’t used anywhere I’m not going to include an example, I’m just mentioning this for your information.
There are a whole series of functions with TIOCLINUX. You use a subcode (somewhat like you do with ICMP functions) to do different things. You may notice some subcodes (such as subcode 2 and 10) also take additional arguments.
TIOCLINUX:
We will show these subcodes in order:
subcode 0:
This is to dump the screen. This is obsolete now, because this is what /dev/vcsX and /dev/vcsaX now (which is what our ACS seen above uses to detect new data). Further note: subcode 0, 8, and 9 have all be replaced by /dev/vcsX and /dev/vcsaX.
subcode 1:
This will return task information. This is now deprecated, so avoid use of it (why would you need to use this?).
subcode 2:
This works with subcode 3 as well. This is for cutting and pasting. You pass it a struct that contains the subcode, the start row column, the end row and column, and the selection mode (0 for character by character, 1 for word-by-word, 2 for line-by-line cut and selecting). The characters selected (or cut) are highlighted and put into a buffer that is in the sel_buffer (in linux/drivers/char/console.c). The argument is a pointer to a struct that looks like this:
struct {
char subcode; /* this will be 2 */
short xs; /* where to start cutting (0 = left side of screen) */
short ys; /* where to start cutting (0 = top of the screen) */
short xe; /* where to end the cutting */
short ye; /* where to end the cutting */
}
subcode 3:
This works with subcode 2. subcode 2 cuts out some test from the console and this pastes it to the fd (from the sel_buffer mentioned above in subcode 2).
subcode 4:
This will unblank the screen (this is what happens when the screen saver comes on and then you hit a key).
subcode 5:
This is to set the lookup table defining characters in a “word”, for word-by-word selection. It is user settable table that defines the characters that are considered to be alphabetic. This will be stored in inWordLut (which is in linux/drivers/char/selection.c.
It looks like this:
static u32 inwordLut[8] = {
0x00000000, /* control chars */
0x03FF0000, /* digits */
0x87FFFFFE, /* uppercase and ‘_’ */
0x07FFFFFE, /* lowercase */
0x00000000,
0x00000000,
0xFF7FFFFF, /* latin-1 accented letters, not multiplication sign */
0xFF7FFFFF /* latin-1 accented letters, not division sign */
};
subcode 6:
This will return the shift_state. The argument passed to ioctl() is a pointer to a char.
subcode 7:
This will return the report_mouse. The argument passed to ioctl() is a pointer to a char.
subcode 8:
This dumps the screen height, cursor position, and all character attribute pairs. This is obsolete now and the kernel will report an error if you try to use it. This is because we now have /dev/vcsX and /dev/vcsaX and you can just read from there. Only use this if you have a kernel between 1.1.67 and 1.1.92.
subcode 9:
This will restore the width and height, cursor position, and all character attributes. If you try to use this in anything later than 1.1.92 you will get an error. Write to /dev/vcsX or /dev/vcsaX instead.
subcode 10:
This is what handles the power saving for new generation monitors. If you are idle for so long the screen will blank. The argument passed to this will be a pointer to a structure that includes the subcode (which will be 10) and one of the following types:
0: Screen blanking is disabled.
1: Video adapter registers are saved and the monitor is put into standby mode (it turns off vertical sychronization pulses). If your monitor has an Off_Mode timer, it will eventually power down by itself.
2: The settings are saved and then it turns the monitor off (it turns off both vertical and horizontal sychronization pulses. If your monitor doesn’t have an Off_Mode timer, or you want your monitor to power down immediately when the blank_timer times out, use this.
We will use the following structure:
struct {
char subcode; /* This will be 10 */
char mode; /* 0: disable screen blanking */
/* 1: go into “standby” mode */
/* 1: go into “off” mode */
}
Conclusion:
I am sorry for the length of this article, but I wanted to give examples for many of these to show the uses of console IOCTLs. As I mentioned in the introduction, IOCTLs are being replaced by POSIX, but this is better. Why do you need console IOCTLs? There are a lot of undocumented things that you can do with console IOCTLs you can’t do otherwise (for example, ACS and CAP).