UTD User Manual
25
The Touch Driver in Detail
Architecture:
The touch controllers are exposed as evdev devices in
/dev/input/eventX
. By default they are recognized as mouse by the
kernel and all events are routed to a
/dev/input/mouseX
device which is
also automatically used by the xorg server. Some newer touchscreen de-
vices may not be recognized at all by the X-Server though, because of an
unknown product/vendor id, these will only be functional with a version of
wntouch that knows and translates their events to mouse clicks or touch
events.
The raw input events generated by the original device files do not allow
any
calibration and advanced processing support, therefore wntouch inserts an
additional abstraction
layer by means of the developed driver. As stated by the requirement, this
abstraction layer is completely in user-space and implemented with a
daemon program called
wntouch
. wntouch will scan all devices in
/dev/input/
for supported touchscreen controllers. Whenever it finds a
matching input device it will open it and request for exclusive access. This
will stop further processing of the incoming events by the kernel and con-
version to mouse events. To allow Xorg to use the device, wntouch will
create a new evdev device named
wntouchX
(the internal evdev name of
a device can be seen using the evtest tool). Additionally it will create a link
in
/dev/input/wntouchX
to the newly created
eventX
device so that it
can be referred directly in configuration files.
With version 2.1.x of the driver, an accompanying userspace tool called
wnmapping
is used to map monitors and touch devices correctly, using the
xinput2 component of Xorg, so the former manual screen calibration be-
comes optional. Also, second mouse button clicks can be emulated in
mode “mouse” by long presses on the touchscreen surface, which is con-
figured in
/etc/opt/wn/wntouch/rightclick
(default off).
The wntouch daemon is controlled by commandline options which are
parsed from variables in
/etc/opt/wn/wntouch/options
, which are
