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: https://share.toradex.com/5hhtyf11ec2qjqj and just do a COPY followed by a dpkg -i <name of .deb> instead of apt install touch2pointer.

1 Like
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.

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: High performance, low power Embedded Computing Systems | 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
16

Good news - I was able to get it working as expected though I did run into some other issues.

Namely, Weston will get upset and refuse to launch if I bind-mount the entire /dev folder - something about failing to initialize the DRM backend, but separately mounting the various /dev entities required will work.

I donā€™t think /dev/input/eventX entries are stable if the available input devices change, so I also added some udev rules to detect the touchscreen and add a fixed node at /dev/input/touchscreen0 so I can supply a fixed argument to the container in the dockerfile.

SUBSYSTEM=="input", KERNEL=="event[0-9]*", ENV{ID_MODEL}=="ILITEK-TP", RUN+="/bin/mknod /dev/input/touchscreen0 c $major $minor", ENV{LIBINPUT_IGNORE_DEVICE}="1"

Additionally the following changes were made to the entry.sh script:

	--touch2pointer)
		shift
		if [ -c "$1" ]; then
			/usr/bin/touch2pointer "$1" &
		else 
			echo "Failed to bind touchscreen $1"
		fi
		;;

and adding a : after touch2pointer in the OPTIONS var (otherwise the parameter is passed through to weston itself):

OPTIONS=developer,touch2pointer:,no-change-tty,tty:
17

Glad to hear you were able to get something working!

Namely, Weston will get upset and refuse to launch if I bind-mount the entire /dev folder - something about failing to initialize the DRM backend, but separately mounting the various /dev entities required will work.

Could you elaborate on this point. Almost all of our documentation launches the Weston container with all of /dev bind-mounted and there has been no issues for us before. Or maybe is this just specific to your x86 platform?

Best Regards,
Jeremias

18

Sure, hereā€™s the log:

$ docker compose -f broken.yml up desktop
[+] Running 2/0
 ā æ Network torizon_default      Created                                                                                                                                                                                                        0.0s
 ā æ Container torizon-desktop-1  Created                                                                                                                                                                                                        0.0s
Attaching to torizon-desktop-1
torizon-desktop-1  | DEV mode detected. ARGS: --no-change-tty --tty=/dev/tty0 --touch2pointer=/dev/input/touchscreen0
torizon-desktop-1  | Cannot detect SoC! Assuming it's GPU-capable.
torizon-desktop-1  | SoC has GPU: true
torizon-desktop-1  | SoC has DPU: false
torizon-desktop-1  | g2d implementation: viv
torizon-desktop-1  | Removing previously created '.X*-lock' entries under /tmp before starting Weston. Pass 'IGNORE_X_LOCKS=1' environment variable to Weston container to disable this behavior.
torizon-desktop-1  | dos2unix: converting file /etc/xdg/weston/weston.ini to Unix format...
torizon-desktop-1  | dos2unix: converting file /etc/xdg/weston-dev/weston.ini to Unix format...
torizon-desktop-1  | 00:00:00.000 [INFO] [seatd/seat.c:39] Created VT-bound seat seat0
torizon-desktop-1  | 00:00:00.000 [INFO] [seatd/seatd.c:194] seatd started
torizon-desktop-1  | Date: 2023-09-27 UTC
torizon-desktop-1  | [16:18:01.643] weston 10.0.1
torizon-desktop-1  |                https://wayland.freedesktop.org
torizon-desktop-1  |                Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
torizon-desktop-1  |                Build: 10.0.1
torizon-desktop-1  | [16:18:01.643] Command line: weston -Bdrm-backend.so --current-mode -Swayland-0
torizon-desktop-1  | [16:18:01.643] OS: Linux, 5.15.71-torizon-standard, #1 SMP PREEMPT Mon Jul 11 02:56:53 UTC 2022, x86_64
torizon-desktop-1  | [16:18:01.643] Flight recorder: enabled
torizon-desktop-1  | [16:18:01.643] Using config file '/etc/xdg/weston-dev/weston.ini'
torizon-desktop-1  | [16:18:01.643] Output repaint window is 7 ms maximum.
torizon-desktop-1  | [16:18:01.643] Loading module '/usr/lib/x86_64-linux-gnu/libweston-10/drm-backend.so'
torizon-desktop-1  | [16:18:01.645] initializing drm backend
torizon-desktop-1  | [16:18:01.645] Trying logind launcher...
torizon-desktop-1  | [16:18:01.646] logind: cannot find systemd session for uid: 1000 -61
torizon-desktop-1  | [16:18:01.646] logind: cannot setup systemd-logind helper error: (No data available), using legacy fallback
torizon-desktop-1  | [16:18:01.646] Trying weston_launch launcher...
torizon-desktop-1  | [16:18:01.646] could not get launcher fd from env
torizon-desktop-1  | [16:18:01.646] Trying direct launcher...
torizon-desktop-1  | [16:18:01.646] fatal: drm backend should be run using weston-launch binary, or your system should provide the logind D-Bus API.
torizon-desktop-1  | [16:18:01.646] fatal: failed to create compositor backend
torizon-desktop-1  | Internal warning: debug scope 'drm-backend' has not been destroyed.
torizon-desktop-1  | 00:00:00.029 [INFO] [seatd/seatd.c:218] seatd stopped
torizon-desktop-1  | /usr/bin/entry.sh: line 244: OLD_VT: unbound variable
torizon-desktop-1 exited with code 1

and this is the compose:

version: "2.4"
services:
  desktop:
    image: weston:latest
# Required to get udev events from host udevd via netlink
    network_mode: host
    volumes:
      - "/tmp:/tmp"
      - type: bind
        source: /dev
        target: /dev
      - "/run/udev:/run/udev:ro"
      - source: /var/volatile/DEV_STATE
        target: /DEV_STATE
        type: bind
        read_only: true
    cap_add:
      - CAP_SYS_TTY_CONFIG
    # Add device access rights through cgroup...
    device_cgroup_rules:
      # ... for tty0,1,7
      - 'c 4:* rmw'
      - 'c 10:* rmw'
      # ... for /dev/input devices
      - 'c 13:* rmw'
      - 'c 199:* rmw'
      # ... for /dev/dri devices
      - 'c 226:* rmw'
    healthcheck:
        test: ["CMD", "test", "-S", "/tmp/.X11-unix/X0"]
        interval: 2s
        timeout: 4s
        retries: 15
        start_period: 2s
    command: --no-change-tty --tty=/dev/tty0 --touch2pointer=/dev/input/touchscreen0

The only change between this and a working instance is the devices/volumes section, namely, these entries and not having a blanket /dev bind:

   devices:
      - /dev/uinput
    volumes:
      - "/tmp:/tmp"
      - "/dev/dri:/dev/dri"
      - "/dev/galcore:/dev/galcore"
      - type: bind
        source: /dev/input
        target: /dev/input

and the logs diverge after ā€œTrying direct launcherā€:

torizon-desktop-1  | [16:21:41.040] Trying weston_launch launcher...
torizon-desktop-1  | [16:21:41.040] could not get launcher fd from env
torizon-desktop-1  | [16:21:41.040] Trying direct launcher...
torizon-desktop-1  | [16:21:41.041] WARNING! Succeeded opening /dev/dri/card0 as non-root user. This implies your device can be spied on.
torizon-desktop-1  | [16:21:41.041] using /dev/dri/card0
torizon-desktop-1  | [16:21:41.041] DRM: supports atomic modesetting
torizon-desktop-1  | [16:21:41.041] DRM: supports GBM modifiers
torizon-desktop-1  | [16:21:41.041] DRM: supports picture aspect ratio
etc. etc.
19

As I said bind-mounting all of /dev works fine on my side for launching the Weston container. However, comparing our logs I notice a difference. Hereā€™s my logs:

Switching VT tty1 to text mode if currently in graphics mode
Switching to VT 7
SoC is: 'i.MX8QM'
SoC has GPU: true
SoC has DPU: true
g2d implementation: dpu
Removing previously created '.X*-lock' entries under /tmp before starting Weston. Pass 'IGNORE_X_LOCKS=1' environment variable to Weston container to disable this behavior.
dos2unix: converting file /etc/xdg/weston/weston.ini to Unix format...
dos2unix: converting file /etc/xdg/weston-dev/weston.ini to Unix format...
00:00:00.000 [INFO] [seatd/seat.c:39] Created VT-bound seat seat0
00:00:00.000 [INFO] [seatd/seatd.c:194] seatd started
Date: 2023-09-27 UTC
[17:14:51.546] weston 10.0.1
               https://wayland.freedesktop.org
               Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
               Build: lf-5.15.52-2.1.0-10-g9452feba
[17:14:51.547] Command line: weston -Bdrm-backend.so --current-mode -Swayland-0
[17:14:51.547] OS: Linux, 5.15.77-6.4.0-devel+git.ddc6ca4d76ea, #1-TorizonCore SMP PREEMPT Thu Jun 29 10:14:22 UTC 2023, aarch64
[17:14:51.547] Flight recorder: enabled
[17:14:51.547] Using config file '/etc/xdg/weston-dev/weston.ini'
[17:14:51.548] Output repaint window is 7 ms maximum.
[17:14:51.548] Loading module '/usr/lib/aarch64-linux-gnu/libweston-10/drm-backend.so'
[17:14:51.559] initializing drm backend
[17:14:51.559] Trying libseat launcher...
00:00:00.065 [INFO] [seatd/server.c:145] New client connected (pid: 29, uid: 1000, gid: 1000)
00:00:00.065 [INFO] [seatd/seat.c:170] Added client 7 to seat0
00:00:00.065 [INFO] [seatd/seat.c:480] Opened client 7 on seat0
[17:14:51.560] libseat: session control granted
[17:14:51.565] using /dev/dri/card1
...

Notice in my logs it uses the libseat/seatd:

[17:14:51.559] Trying libseat launcher...

Which is expected since in our Weston Bookworm containers, the entry script uses seatd-launch to initialize the Weston process: https://github.com/toradex/torizon-containers/blob/bookworm/debian-docker-images/weston/entry.sh#L255

However in your logs it seems to be using logind for some reason?:

torizon-desktop-1  | [16:18:01.645] Trying logind launcher...

If I run our Bullseye Weston container (with all of /dev bind-mounted) I see something about logind in the logs. Though still not quite exactly the same as what is seen in your logs:

NXP EULA has already been accepted.
SoC is: 'i.MX8QM'
SoC has GPU: true
SoC has DPU: true
g2d implementation: dpu
Removing previously created '.X*-lock' entries under /tmp before starting Weston. Pass 'IGNORE_X_LOCKS=1' environment variable to Weston container to disable this behavior.
dos2unix: converting file /etc/xdg/weston/weston.ini to Unix format...
dos2unix: converting file /etc/xdg/weston-dev/weston.ini to Unix format...
NXP EULA has already been accepted.
touch: cannot touch '/tmp/nxp-eula-accepted': Permission denied
touch: cannot touch '/tmp/nxp-eula-accepted': Permission denied
Date: 2023-09-27 UTC
[17:39:00.670] weston 9.0.0
Date: 2023-09-27 UTC
[17:39:00.670] weston 9.0.0
               https://wayland.freedesktop.org
               https://wayland.freedesktop.org
               Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
               Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
               Build: 9.0.0
               Build: 9.0.0
[17:39:00.671] Command line: /usr/bin/weston
[17:39:00.671] Command line: /usr/bin/weston
[17:39:00.671] OS: Linux, 5.15.77-6.4.0-devel+git.ddc6ca4d76ea, #1-TorizonCore SMP PREEMPT Thu Jun 29 10:14:22 UTC 2023, aarch64
[17:39:00.671] OS: Linux, 5.15.77-6.4.0-devel+git.ddc6ca4d76ea, #1-TorizonCore SMP PREEMPT Thu Jun 29 10:14:22 UTC 2023, aarch64
[17:39:00.671] Using config file '/etc/xdg/weston-dev//weston.ini'
[17:39:00.672] Output repaint window is 7 ms maximum.
[17:39:00.671] Using config file '/etc/xdg/weston-dev//weston.ini'
[17:39:00.672] Output repaint window is 7 ms maximum.
[17:39:00.672] Loading module '/usr/lib/aarch64-linux-gnu/libweston-9/drm-backend.so'
[17:39:00.672] Loading module '/usr/lib/aarch64-linux-gnu/libweston-9/drm-backend.so'
[17:39:00.681] initializing drm backend
[17:39:00.681] initializing drm backend
[17:39:00.682] logind: not running in a systemd session
[17:39:00.682] logind: cannot setup systemd-logind helper (-61), using legacy fallback
[17:39:00.682] logind: not running in a systemd session
[17:39:00.682] logind: cannot setup systemd-logind helper (-61), using legacy fallback
[17:39:00.687] using /dev/dri/card1
...

However, this ends up still working fine, despite the error messages from logind. Given that, perhaps are you mixing the entry script from bullseye with the container for bookworm or something like that?

Best Regards,
Jeremias

20

I donā€™t believe so - I just double checked and the branch I have checked out on which my work was based is the bookworm branch of the public torizon-containers repository - just built for x64 instead of ARM.

21

Well at this point weā€™ll probably have to chalk it up to differences between the standard Torizon system and your x86 setup. Not sure how much more I can dig into this since it just works as is on my side. In any case you have a working method with the more narrow /dev/* bind-mounts.

With that said, is there anything else blocking you on this topic?

Best Regards,
Jeremias

22

Nope, I think weā€™re in good shape now, thanks for the assistance.

23

Glad I was able to assist!

1 Like