Tinycore: Screenshots 







Taking a ScreenShot

(Or customising your keyboard)


Sample screenshot Tinycore includes a script - that can be used to take a snapshot of the current screen. It is a full screen dump not just a dump of the active window. There is a variant of named which will do the latter.

The screenshot script can be run by right-clicking on the desktop and then selecting SystemTools and then screenshot. I found this way of taking a screen shot didn't work for me where I was wanting to include various drop-down menus in the screen shot. Move the cursor off them or right click to bring up the screenshot menu and all the other menus disappeared.

Anyway I like the ease of just hitting the 'PrintScreen key' rather than doing a right-click and then navigating through a couple of menus.


The answer to this lies in actkbd by Theodoros V. Kalamatianos (thkala) which was last updated in 2014. I found it still works and it is also included in the apps library for Tiny Core 8.2.1. It took me a little while to sort out the necessary configuration and how to run it, but in the end it was very simple.

From the README file:

actkbd is a simple daemon that binds actions to keyboard events. It recognises key combinations and can handle press, repeat and release events.

It has significant capabilities, but all I was interested in was triggering whenever the Print Screen key was pressed.

The script automatically saves the screenshot to the home directory of whoever triggered it. In this case the trigger is actually the actkbd daemon which is running as root. This means the screen shots are saved in the root directory, are volatile and vanish on a reboot. I haven't yet looked into how to change this but it is not something that worries me at the moment.

Read the documentation

The documentation includes the paragraph:

In most Linux systems the device nodes to use are named /dev/input/eventX, where X is a decimal unsigned number, e.g. /dev/input/event0. If the /proc filesystem is mounted and accessible, actkbd should be able to detect a usable keyboard device. You should not need to manually specify one, unless there are multiple keyboards present.

It took a while for me to realise that the lack of success I was having was due to the fact that actkbd was not actually hooked into the keyboard. I then went back and read the documentation properly. There I found the paragraph that followed from the above:

Update: On newer kernels several special buttons (like the Power switch) may appear as input devices as well. There is no way for the auto-detection code to tell them apart and it is quite possible that the actual keyboard will not be the one actkbd will select. Using udev to start actkbd is the best way to avoid this problem.

At the end of this article I cover my (unsuccessful) attempt to use udev to start the daemon, but I did come up with a way to automatically find the right device to use.

Configuration File

actkbd looks for its configuration file in /usr/local/etc. There is an example file there, but in practice you can ignore it. For our requirement - one simple key press to trigger the screen dump - you just need to create a very simple file:

# actkbd config file for Print Screen
which is saved as actkbd.conf. Basically, when actkbd sees scan code 99 (the scan code of the Print Screen key) it executes the screenshot code.

Jumping ahead a bit, once you've got actkbd to run, you can run it from a terminal with the parameters -n and -s. The -n stops it executing any commands and the -s gets it to show the key presses. For example, in a terminal window type:

sudo actkbd -n -s -d /dev/input/event2

The output from hitting some keys on the keyboard is shown below. In this example I've hit the following keys: Print Screen, F9, F7, shift+F7. (For clarity I've removed some of the other dross that appears).


...which is an easy way of finding the key codes for any keys you may wish to setup.

Type Ctrl/C to get out of it.

Run parameters

As noted above I found that the daemon was unable to automatically find the correct interface for the keyboard. This means we have to pass it the right information via the command line. The daemon is started with the command:

sudo actkbd -D -q -d /dev/input/eventX

where the 'eventX' identifies the keyboard. (In my case it turned out to be event2 on my test system, but event3 on another system).

The simple way I took to find this out was to have a quick look in the dmesg output to find the keyboard....

tc@rebuild:~$ dmesg | grep eyboard
hid-generic 0003:04F3:0103.0001: input,hidraw0: USB HID v1.11 Keyboard [HID 04f3:0103] on usb-0000:00:13.0-1/input0

...which showed that my USB keyboard was tagged as [HID 04f3:0103]

A quick check of the input devices in /proc/bus/input/devices threw up an entries of:

tc@rebuild:~$ cat /proc/bus/input/devices
I: Bus=0003 Vendor=04f3 Product=0103 Version=0111
N: Name="HID 04f3:0103"
P: Phys=usb-0000:00:13.0-1/input0
S: Sysfs=/devices/pci0000:00/0000:00:13.0/usb5/5-1/5-1:1.0/0003:04F3:0103.0001/input/input5
U: Uniq=
H: Handlers=sysrq kbd leds event2 
B: EV=120013
B: KEY=10000 7 ff800000 7ff febeffdf f3cfffff ffffffff fffffffe
B: MSC=10
B: LED=7
I: Bus=0003 Vendor=04f3 Product=0103 Version=0111
N: Name="HID 04f3:0103"
P: Phys=usb-0000:00:13.0-1/input1
S: Sysfs=/devices/pci0000:00/0000:00:13.0/usb5/5-1/5-1:1.1/0003:04F3:0103.0002/input/input6
U: Uniq=
H: Handlers=kbd event4 
B: EV=1f
B: KEY=3007f 0 0 0 0 483ffff 17aff32d bf544446 0 0 1 130c13 b17c000 267bfa d941dfed 9e1680 4400 0 10000002
B: REL=40
B: ABS=1 0
B: MSC=10

Based on the line:

H: Handlers=sysrq kbd leds event2 

I decided that the earlier entry was of interest and the device we were after was /dev/input/event2. Subsequently I discovered that keyboards always have an EV entry of 120013.

As noted earlier, at this stage you can check things out by running actkbd with the parameters -n and -s.

sudo actkbd -n -s -d /dev/input/event2

If it's producing output when you type on the keyboard then everything's fine. Type Ctrl/C to get out of it.

Saving your setup

As always with Tiny Core you need to save changed (or new) configuration files by adding them to the /opt/.filetool.lst file and then running -b.

Automatic start up

After I discovered that keyboards are always identified by EV=120013 I wrote a simple perl script to automatically find the right eventN file and then launch actkbd.

use strict;
use warnings;

# Scan the file /proc/bus/input/devices to find the eventN queue for the keyboard,
# and then launch actkbd.
# Keyboard can apparently can be identified by the entry where EV=120013.
# example:
#	......
#	U: Uniq=
#	H: Handlers=sysrq kbd leds event2 
#	B: PROP=0
#	B: EV=120013
#	......

open(DEVICES, '<', "/proc/bus/input/devices" ) || die ("Can't open devices file\n");
my $line;
while( $line=<DEVICES> ) {
my $event;
	next if( !($line =~ m/^H:\sHandlers=.*kbd.*(event[0-9]+)/ ));
	$event = $1;
	$line=<DEVICES>;	# discard next line
	if( $line =~ m/EV=120013/ ) {
		print "Launching actkbd on $event\n";
		exec "sudo /usr/local/sbin/actkbd -D -q -d /dev/input/$event";

I gave this the name and saved it in the directory /opt/bin. Not a convential place, but /opt is persistent and saves fiddling with .filetool.lst. Also I regularly backup my /home and /opt directories and use those backups whenever I decide to switch to new hardware and/or update Tiny Core.

Normally for something like this feature you would add the start-up command to That way it is automatically loaded and 'on tap' whenever you want to use it. It looks like you can't do this here as X is not running at the time actkbd is launched and so the context isn't right when it tries to run The answer is to create a simple text file in user tc's .X.d directory (/home/users/tc/.X.d) that runs the perl script given above. The name of the file doesn't matter.


Once X is started it runs whatever files it finds in a user's .X.d directory. With actkbd started this way it has no problems running when the Print Screen key is pressed.


I couldn't get this to work, you may do better (and let me know if you do!). The documentation suggested all that was necessary was to create a rules file along the lines:

# udev rules for keyboards
ACTION=="add", SUBSYSTEM=="input", KERNEL=="event[0-9]*", GOTO="_INPUT_"

DRIVERS=="actkbd", ENV{__CFG}="/usr/local/etc/actkbd.conf", GOTO="_KBD_"

RUN+="/usr/sbin/actkbd -q -D -c %E{__CFG}"

# End

I saved this as /etc/udev/rules.d/96-actkbd.rules.

Enabling syslog and checking the log files showed that this was being executed but I never ended up with a running actkbd daemon.

Looking at the above I don't immediately see how it helps in ensuring the right 'event' is selected. Possibly because it is invoked immediately after the keyboard is added?


My thanks to those who responded to my questions on the Tiny Core TCE Q&A Forum on this topic and helped me along the way. e.g. To use the .X.d directory to launch actkbd.


Any comments? email me. Added January 2018