1. Introduction
Although an old and fairly primitive device and concept, the keyboard is still an essential computer interface. Even with common devices like touch screens, touch pads, and the computer mouse, data entry is often reduced to text. In fact, even touch-based user interfaces usually employ at least a virtual (on-screen) keyboard. On the other hand, some devices, such as laptops, have embedded physical keyboards.
In this tutorial, we’ll talk about disabling the internal keyboard of laptops. First, we talk about input source handling. After that, we go through different ways of disabling a keyboard.
We tested the code in this tutorial on Debian 12 (Bookworm) with GNU Bash 5.1.4. It should work in most POSIX-compliant environments unless otherwise specified.
2. Input Source Handling
Systems can have many streams of input:
- terminal
- keyboard
- mouse, touchpad
- touch screen
- GPIO (General-Purpose Input Output)
Each stream can further be controlled by different parts of the operating system (OS) and applications such as the kernel, drivers, purpose-built software, as well as a windowing system like X11 X Server. In fact, most devices require support and provide control on multiple levels.
For example, keyboard usage follows an expected but multi-step pattern:
- hardware recognition through a port like USB (Universal Serial Bus) or PS/2 (Personal System /2) on the motherboard
- kernel configuration influences processing
- drivers understand incoming key signals and interpret them accordingly
- userspace handling of the already interpreted signals
While we can have control at each step, the last one is usually where we can make relatively simple but fundamental modifications. For instance, key combinations exist on all levels but are mostly part of software like the windowing system and terminal emulators.
On the other hand, should we want to prevent any processing of the input from a given device, we usually aim to start as early as possible on the chain:
- unplug
- remove or turn off kernel support
- uninstall or disable drivers
- prevent user-space software from handling data from the device
Since we can mostly visualize these steps as a hierarchy in an upside-down tree form, metaphorically cutting an upper branch is naturally easier than trimming leaves:
+----------+
| Keyboard |
+-----+----+
|
+------+------+
| PS/2 | USB |
+-------------+
| Wireless |
+------+------+
| Motherboard |
+------+------+
|
+--------+---------+
| Kernel | Drivers |
+--------+---------+
| Configuration |
+--------+---------+
|
+----------+----------+
| X Server | Terminal |
+----------+----------+
| Terminal Emulator |
+---------------------+
| User-space Software |
+---------------------+
In the (modified) words of a now-infamous personality: When there’s no *keyboard*, there’s no *way to use it*.
3. Unplug
Indeed, if we remove the physical, electrical, or wireless connection between a device and the motherboard, it stops functioning.
Yet, applying that to our case might not be so simple due to the potential complications of servicing hardware:
- unscrew laptop cover
- open bottom and top of laptop shell
- gently lift keyboard
- find keyboard connector
- disconnect keyboard
Even if we do reach this point, there are different ways of connecting the internal keyboard to the motherboard of a laptop. In fact, some can involve a soldered connector, which is yet another step to overcome.
Because of the potential danger and permanence of physically altering hardware, it’s usually a better approach to go the software route.
4. Kernel Support
If we check the official guide of available kernel parameters, we can find i8042.nokbd as a way to disable the internal laptop keyboard.
While the official description of i8042.nokbd is Don’t check/create keyboard port, we are free to use this option as it shouldn’t affect external USB keyboards:
$ cat /etc/default/grub
[...]
GRUB_CMDLINE_LINUX_DEFAULT="quiet i8042.nokbd"
[...]
As usual, when it comes to kernel boot parameters, the standard GRUB files are usually the best option:
- /etc/default/grub, in GRUB_CMDLINE_LINUX
- /etc/grub.conf, on the kernel line
Naturally, these vary according to the bootloader.
After applying the setting, we just run update-grub. After the next boot, we should have a non-functioning keyboard.
5. Drivers
One primitive way to disable the internal keyboard is to find the appropriate driver within the kernel drivers path:
$ ls /lib/modules/$(uname --kernel-release)/kernel/drivers/hid
hid-a4tech.ko hid-gfrm.ko hid-multitouch.ko hid-samsung.ko
hid-accutouch.ko hid-gt683r.ko hid-nti.ko hid-sensor-custom.ko
hid-alps.ko hid-gyration.ko hid-ntrig.ko hid-sensor-hub.ko
hid-appleir.ko hid-holtekff.ko hid-ortek.ko hid-sjoy.ko
...
Here, we use ls to show the contents of /lib/modules/$(uname –kernel-release)/kernel/drivers/hid. Within the path, we interpolate the command substitution of uname –kernel-release to get the proper kernel version.
Next, we can disable the appropriate driver or drivers:
$ rm /lib/modules/$(uname --kernel-release)/kernel/drivers/hid/usbhid/*
In this case, we directly remove the driver. Of course, it’s usually a better idea to use purpose built tools.
6. modprobe
The modprobe system for handling kernel modules provides another way to disable the internal laptop keyboard.
Specifically, we leverage the blacklist command within a file in the modprobe.d directory:
$ cat /etc/modprobe.d/100-kbdisable.conf
blacklist usbhid
This way, we prevent the relevant module (driver) from being loaded on boot.
In this case, since the driver is still available, we can reload it if we reconsider:
$ insmod /lib/modules/$(uname -r)/kernel/drivers/hid/usbhid/usbhid.ko
Unlike modprobe, insmod doesn’t recognize or follow dependencies or other rules such as blacklists.
7. X Server and xinput
As with most devices, we can also handle their function via the X11 X Server. In particular, the xinput tool is the standard for managing input devices:
$ xinput --list
⎡ Core pointer id=2 [master pointer (3)]
⎜ ↳ Core xost pointer id=4 [slave pointer (2)]
⎜ ↳ HID-compliant Mouse id=6 [slave pointer (2)]
⎜ ↳ TPPS/2 IBM TrackPoint id=10 [slave pointer (2)]
⎣ Core keyboard id=3 [master keyboard (2)]
↳ Core xost keyboard id=5 [slave keyboard (3)]
↳ Power Button id=7 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=8 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=9 [slave keyboard (3)]
Here, we use the tool to get all related devices on the system in a hierarchy. The master devices have associated slave devices under them. Devices have a potentially non-unique name in the first column and a unique id in the second.
Critically, trial and error are usually necessary to identify which of the last two keyboards is external. Still, the first one (id=8) is usually the internal keyboard on laptops.
Once we have the basic list, we can perform actions with devices:
- status: –enable and –disable a device
- mappings: –set-button-map that relates physical to logical buttons for a device
- properties: –set-prop, –set-int-prop, –set-float-prop, –delete-prop, and –watch-props to handle properties of a device
- feedbacks: –set-ptr-feedback, –set-integer-feedback, –get-feedbacks to handle feedbacks of a device during operation
- testing: –test basic or –test-xi2 device events
- state: –query-state of device keys
- control: –create-master, –remove-master, –float slave, and –reattach slave to handle master and slave devices
In fact, the –enable and –disable options are a shorthand way to write a property setting:
$ device='AT Translated Set 2 keyboard'
$ xinput --set-prop $device 'Device Enabled' 0; sleep 10; xinput --set-prop $device 'Device Enabled' 1
Here, we assign the keyboard device name to the $device variable. It’s usually better to use the unique id instead. After that, we run a one-liner to perform three actions:
- set the Device Enabled property of $device to 0, disabling the device
- sleep for 10 seconds, during which $device is disabled and unusable
- set the Device Enabled property of $device to 1, enabling the device
Alternatively, we can –float the device and then –reattach it:
$ device=8
$ xinput --float $device; sleep 10; xinput --reattach $device
Critically, we use a single command line, as otherwise, we might have to use the mouse to reenable the keyboard.
Finally, there are even graphical utilities to toggle devices.
8. Summary
In this article, we explored ways to disable and enable devices on a Linux system with a main focus on the internal keyboard of a laptop.
In conclusion, although there are many methods to control devices, the correct one depends on the current situation since a broken keyboard doesn’t usually require the same actions as an unnecessary one.