How to integrate a TouchScreen driver (shell script provided)

device
1

Hello,

i’m trying to create a Core amd64 image to use on a pc with a resistive touch screen (http://www.eeti.com/drivers_Linux.html).

The driver is provided with a setup.sh file with a lot of condition to be used with many distribuitions.

The setup.sh has also a lot of question to answer (Accept conditions, confirm conditions, etc).

Looking at the file it seems that the core of the file will move some driver files and modify some rc.local conditions.

What is the correct procedure to integrate this kind of devices in a core image?

Thanks!

2

i would expect the device to actually be supported on a kernel level (its a simple USB touchscreen), did you try it yet ?

if you need additional userpace tools, you will have to include them in your application snap …

3

Yes, at kernel level the drive is supported, using a classic Ubuntu Distro you only need to dispatch the files in the right destination. It seems only require the hidraw availability.

It’s still not a standard USB touch, i mean, with other display we are testing we just need to plug them and with Core & the Mir Kiosk app and they works without problem.

With this one, also on Classic, we need to install the driver first, but it’s not need any tweak at kernel level.

4

well, on core you need to use mir-kiosk to get a wayland or xwayland display server up … mir uses libinput for all input devices, i dont think you can easily compare that to a classic ubuntu where you can use xorg (with the evdev driver), so i’d try first what you get when simply installing mir on your device (just installing the mir-kiosk snap will already get you a black screen with mouse cursor, that should be enough to see if the touch input works)

that said, there seem to still be some issues even with libinput:

1 Like
5

I’ve tried a 18.04 Server (without X) and installed Mir Kiosk with Wayland via Snap, both on PC and Raspberry CM3 and after running the install script the display plus touch works correctly.

Of course what i’m unable to test is a Core installation cause i cannot simply launch the install script.

Edit: just another information, during the script running one of the question is if the driver will be used on a X based enviroment. Using mir-kiosk i’ve replyed no, and it still works fine.

6

ok, if yyou have it working on classic using mir-kiosk, then you should be able to include their daemon in your application snap (simply add an additional part to your snapcraft.yaml that installs it) and create a startup entry in the apps section to make it run the daemon …

we might potentially need to take a look at interfaces depending on what the daemon tries to access on the system.

nontheless it would be better to use libinput without any external hacks (userspace daemons) … the bug suggests that a simple udev rule might be enough

7

Thank you, i’ve done the most preparatory test i can, but now i’m stuck on how to do the next steps.

I’m in trouble to find related docs, could you please provide some insight? Thank you.

8

well, try core with mir-kiosk and dump the described udev rule into /etc/udev/rules.d/ manually for a start (that dir is writable) and see if that works … (we can perhaps include that rule somehow in the core/core18 snaps so you wont have to jump though any hoops)

if it doesnt work and you insist to use the vendor daemon just do what i wrote above, create a part in your applications snapcraft.yaml that downloads the tarball and extracts it into your snap … then create an apps entry that starts the daemon … after building try the snap in --devmode and use snappy-debug.scanlog from the snappy-debug package to get suggestions about interfaces the snap needs …

1 Like