Touch2Pointer sources?

Technical Support
, , , , ,
1

Where can I find the sources for the touch2pointer application installed in the torizon-base container?

I am working on evaluating TorizonCore on x86 and it seems like this is required for Qt applications on Weston to properly process touch events.

However, the only packages available in the Torizon feed are currently for ARM architectures.

Thank you!

1 Like
3

Hi @bw908,

I’ll mirror the code to our GitHub as soon as feasible and give you an update here.

We already build this package for x86 as well, but it’s not widely available at the moment, you can get it from here: Download - Toradex File Sharing Platform and just do a COPY followed by a dpkg -i <name of .deb> instead of apt install touch2pointer.

1 Like
4
5

Thank you!

6

Are you able to provide any guidance on usage of this tool? The design seems flawed without this tool being present on the host itself:

  • touch2pointer requires access to /dev/uinput which does not exist inside the container (and cannot, because it’s provided by a kernel module)
  • exposing uinput on the host will allow touch2pointer to run, but this creates the catch-22 situation that the new fake device created cannot be seen by the docker container because the container has already started. Either:
  • with --device /dev/input: wayland sees there should be a /dev/input/event14 device and tries to read it but of course it does not exist on /dev/input, and therefore we still do not have pointer events inside weston.
  • with -v /dev/input:/dev/input and a cgroup rule, the device does show up, but weston throws an ‘operation not permitted’ when trying to open the newly created device.

The entry.sh script also seems to have a bug:

while [[ $# -ne 0 ]]; do
	case "$1" in
	--touch2pointer)
		/usr/bin/touch2pointer "$1" &
		;;

where there is a missing shift before touch2pointer - otherwise it attempts to invoke /usr/bin/touch2pointer --touch2pointer.

7

Further follow-up: I was able to get it working by bringing up one container with touch2pointer to create the new fake input event, and then another afterwards with Weston so it can see and access the new device. However, this exposes a new issue, which is that weston processes events from both input sources, resulting in duplicate clicks for controls that can accept touch input events. Most of ours do, but it appears that Qt’s virtual keyboard does not and this is the reason we’d need the touch2pointer application.

8
10

touch2pointer requires access to /dev/uinput which does not exist inside the container (and cannot, because it’s provided by a kernel module)

Does your x86 system not have /dev/uinput then I assume? On TorizonCore this interface exists by default with no containers running:

torizon@apalis-imx6-05228985:~$ ls /dev/uinput
/dev/uinput

In our TorizonCore this is done by enabling the kernel config CONFIG_INPUT_UINPUT. Is it not possible to do the same on your x86 system?

Best Regards,
Jeremias

11

Yes, it has /dev/uinput but the issue relates to the fake device being created on the host (e.g. /dev/input/event14) which the container cannot access or see because it has already started - either it is not there or Weston fails with an insufficient permissions error depending on whether I am using --device or a volume mount for /dev/input. (I do have appropriate cgroup rules specified)

12

I did some playing around here with touch2pointer and I think I found the source of confusion. First of all we do have some short documentation on touch2pointer usage but it appears to be somewhat outdated/incorrect: Working with Weston on TorizonCore | Toradex Developer Center

One aspect that is still correct is that you should create a udev rule like so:

SUBSYSTEM=="input", KERNEL=="event0", ENV{LIBINPUT_IGNORE_DEVICE}="1"

Use the correct event* identifier that corresponds to your touchscreen instead of event0. What this does is make it so that Weston doesn’t react to your touchscreen. That way when touch2pointer is running only the simulated pointer input is taken into account and not the original touch input. That should fix this issue you mentioned here:

However, this exposes a new issue, which is that weston processes events from both input sources, resulting in duplicate clicks for controls that can accept touch input events.

Next I ran touch2pointer inside a Weston container. It is then I noticed you were correct about your statement with there being an issue in the entry script:

The entry.sh script also seems to have a bug:

I’ll bring this up with our team.

In lieu of this bug I spun up a container like so:

docker run -d --privileged --rm --name=weston --net=host --cap-add CAP_SYS_TTY_CONFIG              -v /dev:/dev -v /tmp:/tmp -v /run/udev/:/run/udev/              --device-cgroup-rule='c 4:* rmw' --device-cgroup-rule='c 13:* rmw'              --device-cgroup-rule='c 226:* rmw'              torizon/weston:$CT_TAG_WESTON --developer --tty=/dev/tty7

I used --privileged for blanket permissions for testing purposes, but feel free to narrow the permissions in your case as needed. I then used docker exec to get a shell inside the container and manually executed touch2pointer like this: touch2pointer /dev/input/event5

The virtual input event6 was then created and available in the container since I bind-mounted all of /dev. I was then able to use my touchscreen as a mouse input, this was signified by the mouse cursor following my touch, whereas before it did not.

Therefore it seems like you can make use of touch2pointer with a single container by just bind-mounting all of /dev. That way when the new virtual event* device is created the container will have access to it while it’s already running.

Best Regards,
Jeremias

13

Thanks for the update - I’ll give that a try. I’d previously bind mounted just /dev/input, but perhaps something more is required since it is clearly working for you.

I had indeed seen other notes about libinput’s ignore flag and inferred that making it ignore the touch inputs was a potential path forward (the other being finding out why only Qt’s virtual keyboard is broken in this way but the rest of the UI responds properly to touch events…)

I’ll let you know when I get a chance to make these changes and try them out!

14

Let us know if you have any further issues. As for the issues I did find in my investigation I already went ahead and reported them to our team here.

Best Regards,
Jeremias

1 Like