summaryrefslogtreecommitdiffstats
path: root/src/plugins/generic/touchscreen/README
blob: bed90163295fccb087993392da6b6037e98463f7 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
Generic plug-in for evdev touch events

(a) Using as a QPA generic plug-in

1. set up and connect the touch device
2. install libudev-dev or similar
3. build this plug-in (qmake && make)
4. sudo cp 70-qtouchscreen.rules /etc/udev/rules.d
5. sudo udevadm trigger --subsystem-match=input
6. ./fingerpaint -plugin LinuxTouchScreen:force_window

If automatic detection does not work, use -plugin
LinuxTouchScreen:/dev/input/eventN to explicitly set the device file
name.

By default the surface of the touch device is mapped to the entire
screen. If this is not desired, pass force_window in the plugin
specification as shown in the example above. This will cause mapping
the touch surface to the active window instead.

Only touch events are generated, mouse events are not. This is because
on desktop the touch device will usually act as a single-point mouse
replacement by default. For embedded systems the code could to be
extended to generate also mouse events (by calling handleMouseEvent
for the primary touch point for example).

(b) Using in a compositor

The classes (QTouchScreenHandler, QTouchScreenHandlerThread) are also
suitable for direct inclusion into an application, e.g. a Wayland
compositor. The compositor will then usually register its own
QTouchScreenObserver because relying on the QTouchEvents generated by
the QPA event sender is often not satisfactory, as some low-level
details may get lost, and due to performance reasons.


Known issues:

The udev rule matches any touchpad device. If there are multiple ones,
specify the device as described above.

If no evdev events are read, remove 50-synaptics.conf from
/usr/share/X11/xorg.conf.d and restart X.