Is AceCad driver in the kernel now but somehow disabled?

Hi :slightly_smiling_face: While in the process of fixing xf86-input-acecad I was trying to find out why it was moved to AUR in the first place and stumbled upon acecad.c file in kernel source. Does this mean AceCad driver has been merged into kernel? If so, how come my AceCad tablet doesn’t work any more (it used to work with xf86-input-acecad few years back)? I install kernels through mhwd-kernel, I know nothing about kernel compilation, but some applications when compiled need certain flags to enable extra functionality. Is this the case with the kernel and this driver is simply disabled by default in kernel provided by linux510 package? If so, how do I check that and do I have to recompile the kernel to enable it?

→ ~ uname -r
5.10.7-3-MANJARO

Hello,
If you read the last comment on the AUR page
https://aur.archlinux.org/packages/xf86-input-acecad
the PKGBUILD needs to be edited and changed to this:

#$Id: PKGBUILD 250667 2015-11-11 08:40:44Z andyrtr $
#Maintainer: Jan de Groot jgc@archlinux.org

pkgname=xf86-input-acecad
pkgver=1.5.0
pkgrel=9
pkgdesc="X.Org acecad tablet input driver"
arch=(i686 x86_64)
url="http://xorg.freedesktop.org/"
license=('custom')
depends=('sysfsutils')
makedepends=('xorg-server-devel' 'xorgproto-git')
conflicts=('xorg-server<1.16')
source=(${url}/releases/individual/driver/${pkgname}-${pkgver}.tar.bz2
        assign-local-private-after-allocating.patch)
sha1sums=('410cee68e4435dc95774fb389fcefae1b2ffe3d1'
        '9301020b0ef3c6f2081e957481a88d2e187a7973')

build() {
    cd ${pkgname}-${pkgver}
    patch -Np1 -i "${srcdir}/assign-local-private-after-allocating.patch"
    ./configure --prefix=/usr
    make
    }

package() {
    cd ${pkgname}-${pkgver}

    make DESTDIR="${pkgdir}" install

    install -m755 -d "${pkgdir}/usr/share/licenses/${pkgname}"
    install -m644 COPYING "${pkgdir}/usr/share/licenses/${pkgname}/"
    }

Then build it, reboot the system.

Yeah, I managed to compile it before (didn’t really install it as I was concerned by conflicts with newer ABI) but is it even necessary? It seems to be in the kernel already. Or am I wrong about that?

Just to update: driver didn’t work. I eventually gave up trying to make it work and focused on making it work with libinput. It turned out it was missing only resolution capability, so I added it to Systemd’s HWDB and it works out of the box now. Sent merge request.

Anyone interested in making it work here and now, create a file at the following path with the following content:

# /lib64/udev/hwdb.d/61-tablet.hwdb:
evdev:input:b0003v0460p0004*
 EVDEV_ABS_00=::40
 EVDEV_ABS_01=::40

Then in terminal:

sudo systemd-hwdb update
systemd-hwdb query evdev:input:b0003v0460p0004 # to confirm

Might need a reboot.

2 Likes

This is something I like to see.
A problem was determined. A solution was found. And the solution has been submitted upstream.
Good job. :slight_smile:

1 Like

Took me a year and a half :rofl:

I’m still open to explanation why this driver is in the kernel source and yet the tablet isn’t recognised as xinput device. If anyone happens to know, please, satisfy my curiosity. Cheers!

Yep, @Lolix & I already had that discussion in @cprn’s other thread:

1 Like

If i’m not mistaken, for the same reason why wacom requires the driver. While the kernel has the instruction to recognize it and work with it, xorg needs own instructions to make the bridge between tablet-kernel-applications.
Yeah, much better to follow @Lolix instructions. I realized that my interpretation of PKGBUILD was wrong to the makedepends

1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.