Silead touchscreen

[lhartmann]

Please consider enabling the silead touchscreen driver in the kernel config for x86_64 builds, or providing it as a separate package. There are cheap Intel-based windows/android tablets that use it.

It will still require the user to select the right firmware blob (available from https://github.com/onitake/gsl-firmware) according to which tablet model is in use, but at least recompiling the kernel could be skipped.

[MichaIng]

@lhartmann
Many thanks for your request.

We use the official Debian repo kernel for x86 systems and do not compile kernels ourself. What you might want to try is using the kernel from backports, e.g.

apt install linux-image-amd64/stretch-backports

or

apt install linux-image-amd64/buster-backports

Probably it is in a newer upstream Linux version.

[lhartmann]

I don't believe this is an issue of kernel versions, but maybe of debian's free philosophy versus the firmware blob. The current kernel version on DietPi x86_64 (4.19.0) does have the driver, but it is disabled. Same on the buster-backports kernel (5.4.0).

root@tobalet:/boot# grep -i silead config-4.19.0-8-amd64 
# CONFIG_TOUCHSCREEN_SILEAD is not set
root@tobalet:/boot# grep -i silead config-5.4.0-0.bpo.4-amd64 
# CONFIG_TOUCHSCREEN_SILEAD is not set

Cloned https://salsa.debian.org/kernel-team/linux.git, checked-out v4.19-rc6, enabled module, repackaged, installed new kernel, added firmware, recalibrated xinput, and it works. Having the module pre-enabled would have saved me quite a lot of work (and learning).

I guess this is a won't-fix then?

[MichaIng]

@lhartmann

The current kernel version on DietPi x86_64 (4.19.0) does have the driver, but it is disabled.

Ah I see, okay.

I guess this is a won't-fix then?

Yes indeed. Own kernel compiling is currently due to limited man power out of scope. Also I fear if we start with this, we end up enabling more and more features, blowing up kernel size.

However what I can think of is adding it as optional feature to dietpi-config, which compiles the kernel driver as module (https://github.com/sigboe/gslX68X) and downloads the firmware based on selection. Probably we could even find or create some DKMS implementation, at least an /etc/kernel/postinst.d/ script to re-compile the module automatically on kernel upgrades. Probably we find such already done by someone.

[lhartmann]

Something like this, for /etc/kernel/postinst.d?

#! /bin/sh -e
version="$1"
TMPDIR="/tmp/silead-build-$version-$$"
SRCDIR="/lib/modules/$version/build"
OUTDIR="/lib/modules/$version/kernel/drivers/input/touchscreen/"
URL="https://raw.githubusercontent.com/torvalds/linux/master/drivers/input/touchscreen/silead.c"
SUM="698396a0b070a93b16536e01fd7dc3c4d9bdfeda632822867b65d068b07cbd49"

# Sanity check:
[ -d "$SRCDIR" ] || exit 0
command -v gcc  >/dev/null 2>/dev/null || exit 0
command -v make >/dev/null 2>/dev/null || exit 0

# Create a temporary build directory (about 1MB)
mkdir "$TMPDIR"

# Get module source and validate
wget -q "$URL" -O "$TMPDIR/silead.c"
echo "$SUM  $TMPDIR/silead.c" | sha256sum -c --quiet

# Build
echo "obj-m += silead.o" > "$TMPDIR/Makefile"
make -C "$SRCDIR" M="$TMPDIR" modules

# Install
mkdir -p "$OUTDIR"
cp "$TMPDIR/silead.ko" "$OUTDIR"

# Clean
rm -rf "$TMPDIR"

Did not add firmware download code, but maybe that can be automated via a known-devices table. My tablet is identifiable via dmi/id in sysfs as below. All other info there is bogus/dummy.

root@tobalet:~# cat /sys/devices/virtual/dmi/id/product_name
i892
root@tobalet:~# cat /sys/devices/virtual/dmi/id/bios_vendor 
INSYDE Corp.
root@tobalet:~# cat /sys/devices/virtual/dmi/id/bios_version 
I.D892GIBMR01

[MichaIng]

@lhartmann
Very nice, exactly what I had in mind!

If checksum is wanted, we would need to find another source, since the source can change.

The firmware could be probably selected initially selected via whiptail menu. It does not necessarily need to be updated together with the kernel, so we could leave this up to the user to re-select the firmware for forcing an update?

Hmm auto identification is even better. But it might be possible that one wants to install module+firmware before attaching the screen, so I would keep the ability to select from a full list, scraped from the GitHub repo.