Users can interact with a computer using various input devices : the most obvious are keyboards, mice and joysticks ... but it exists others like intrusion detectors for desktops or servers, dedicated keys or proximity detectors on tablet and so one and so forth.
The Linux kernel exposes raw events of such devices to userspace through a collection of character device nodes : the event interface.
SelEvent is the easiest way Séléné applications can manage such information.

Input events are exposed in /dev/input directory. For example, on an average MID-A10 tablet

laurent@Tablette ~ $ ls /dev/input/
by-path  event0  event1  mice

mice is the touchscreen exposed as a mice (unfortunately, it doesn't work due to lacks of proper drive,r but it's another story).
But what are event0 and event1 ? Let's have a look in /proc/bus/input/devices

laurent@Tablette ~ $ cat /proc/bus/input/device
I: Bus=0019 Vendor=0001 Product=0001 Version=0100
N: Name="axp20-supplyer"
P: Phys=m1kbd/input2
S: Sysfs=/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20-supplyer.28/input/input0
U: Uniq=
H: Handlers=kbd event0
B: PROP=0
B: EV=7
B: KEY=100000 0 0 0
B: REL=0

I: Bus=0019 Vendor=0001 Product=0001 Version=0100
N: Name="sun4i-keyboard"
P: Phys=sun4ikbd/input0
S: Sysfs=/devices/virtual/input/input1
U: Uniq=
H: Handlers=kbd event1
B: PROP=0
B: EV=3
B: KEY=2000000 0 800 c0040 0 0 10000002

The field N indicates which is the driver for this device, so, by extension the signals we can git from it (not something that can be invented). In the example above, "axp20-supplyer" is the driver managing the power supply, consequently, we will here "POWER" key status. "sun4i-keyboard" is for tablet additional keys like VolumeUp, VolumeDown and such. Sometime, this field is more explicit, like 'ImPS/2 Generic wheel mouse".
Field H indicates which kind of messages we will receive ( kbd for keyboard here ), and to which event it is connected (event0).

The full source code can be found here.

The 1st step is to create the event

evt = SelEvent.create('/dev/input/event1', rcv_event)

and the corresponding callback function

function rcv_event()
        print('event received')
        local t, tp, c, v = evt:read()
        print( os.date('%c', t), tp, SelEvent.TypeName(tp), c, SelEvent.KeyName(c), v)
end

evt:read() method will read one by one waiting events and returns

• t - timestamp of the event,
• tp - Type of the event : SelEvent.TypeName() will convert this numeric code to a string.
• c - code of the event : SelEvent.KeyName() will convert this numeric code to an almost human-readable-string
• v - value for the event : for a key, 1 means key press and 0 key release

All codes can be found in file /usr/include/linux/input.h with EV_ prefixe for types and KEY_ for ... keys.

Finally, a classical WaitFor() loop with our SelEvent as argument.

while true do
        local rt = table.pack( Selene.WaitFor(evt) )
        for _,ret in ipairs(rt) do
                if type(ret) == 'function' then
                        ret()
                end
        end
end

Not an issue :

• create as many SelEvents as needed
• Add them in WaitFor()

As example :

evt0 = SelEvent.create('/dev/input/event0', handlekeys0)
evt1 = SelEvent.create('/dev/input/event1', handlekeys1)

then

while true do
        local rt = table.pack( Selene.WaitFor(evt0,evt1) )
        for _,ret in ipairs(rt) do
                if type(ret) == 'function' then
                        ret()
                end
        end
end

Notez-bien : as the callback function as no way to know with SelEvent it has to deal with, you need to create as many callbacks as you have input events.

• Unlike input/output stream like stdin and stdout, input events are linked to the host and not to your session : so if you launch an application remotely, events refer to the machine on which your application is running, not your own.

• It's also possible to use GPIO as input events : have a look at GPIO keys kernel modules

• Events are handled in parallel by all processes that have subscribed to their stream. A side-effect is you will see control characters on your console : annoying for directFB applications !
  The workaround is to disable listing getty console by commenting out tty1 related lines in /etc/inittab