Lenovo X200 w/wacom serial pen screen, no joy in Mageia 6

[waferhead]

Have been trying to get this working off and on for months, came up with a working solution for MGA2-5, but the same setup (or any variation I have tried) results in a non-booting system with MGA6 to date.

Anyone have any luck with a serial wacom table/pent on MGA6?
Everything wacom related is installed.

Ubuntu/Mint/SUSE/Fedora/WinX all find it and configure it in the live DVD or installer completely automagically, and it just works, even with kernel 4.10 etc.

Yes, i searched, nothing for MGA6/current cooker or recent.

EDIT by request: Previous thread with posted working solution for Mageia 2>5
viewtopic.php?f=15&t=4119&p=29535&hilit=wacom#p29535

No error msg, it locks up the machine solid when attempting to load Xorg.

[doktor5000]

It might help if you would actually post what your working solution for mga 2 to 5 was, and also the error message that you get on mga6 during boot.

[waferhead]

info added to first post.

[waferhead]

Work around, but not "solved"
...but this is not "correct" as ~every other distro AFAICT detects and configures this automatically.

Never did figure out how Mint et al load the touchscreen, but I got it working using inputattach

Code: Select all

inputattach --daemon --w8001 --baud 19200 /dev/ttyS0


added to /etc/rc.d/rc.local did the trick, works fine now.

Note:for some later units you need 38400 baud, and the pen+touchscreen versions you are on your own as i can't troubleshoot that
Your serial device may differ depending on model

I only tried this as I used inputattach to get the Wacom pen working in android-x86, before they fixed it properly.

On Mint at least the input subsystem seems to automatically find and configure it relatively early in the boot sequence.

[doktor5000]

On Mint at least the input subsystem seems to automatically find and configure it relatively early in the boot sequence.

Then you should compare the relevant udev rules from Mint to the Mageia ones ...

[waferhead]

On Mint at least the input subsystem seems to automatically find and configure it relatively early in the boot sequence.

Then you should compare the relevant udev rules from Mint to the Mageia ones ...

There are no udev rules, First thing I looked at.
... nor any "saved" xorg.conf etc in mint, it appears to be auto generated at runtime.

I will futz with it some more as I have time.

[doktor5000]

There are no udev rules, First thing I looked at.

Where and how did you look at in particular?

[JMiahMan]

udev rules are normally found in something like:
/lib/udev/rules.d/

You can look through those and see if there's anything to do, or that's similar to your current command. You can also do udev_log="debug" in /etc/udev.conf on the working distro and see what exactly it's doing.

On Fedora there's the /lib/udev/rules.d/70-wacom.rules that's provided by xorg-x11-drv-wacom, look and see if there's something similar for Mageia that's not installed.

This is actually your issue
http://svnweb.mageia.org/packages/cauld ... &r2=614053

I'll see what I can do to fix it.. like becoming a packager here.

[JMiahMan]

Just wondering..
does:

Code: Select all

/usr/bin/isdv4-serial-inputattach /dev/ttyS0


Work as well?

[waferhead]

Just wondering..
does:

Code: Select all

/usr/bin/isdv4-serial-inputattach /dev/ttyS0


Work as well?

EDIT: Yes. works better w/o my fatfingers.
Output looks same as std inputattach, did not need baudrate forced, or may default to 19200
Needs spawned with & or startup waits forever for rc.local to finish.
(effectively same as --daemon flag of std inputattach)

As to where I looked, I looked in /etc/udev/rules.d/ as thats where I have been putting the rules for the Wacom since Mageia 2 (see thread previouly posted there's a how-to somewhere here I wrote)

That setup was pulled from the arch how tos

That setup locks the machine on mga6, thus this thread.
May conflict with wacom rules in xorg driver

inputattach has no issues w/xorg driver

I'll take another pass at figuring out what mint's doing later, but there is nothing in /etc/udev/rules.d/, or wacom/WACf string related in /etc

EDIT: Running udev in debug mode, there is no reference to the wacom pen or touchscreen in /run/udev/links/\x2finput...
so I must conclude that Debian and its children aren't using udev at all for the wacom serial pen/touchscreen initialization.

[waferhead]

(poking around in dmesg in mint)
When the kernel boots, the wacom device appears very early, even before video init as a ACPI PNP device.
( root@X200 ~ # uname -a
Linux X200 4.10.0-26-lowlatency #30~16.04.1-Ubuntu SMP PREEMPT Tue Jun 27 10:54:13 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux )

Code: Select all


  0.214554] system 00:01: [mem 0xfed40000-0xfed44fff] has been reserved
[    0.214557] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.214645] pnp 00:02: Plug and Play ACPI device, IDs PNP0b00 (active)
[    0.214682] pnp 00:03: Plug and Play ACPI device, IDs LEN0010 PNP0303 (active)
[    0.214720] pnp 00:04: Plug and Play ACPI device, IDs IBM3780 PNP0f13 (active)
[    0.214807] pnp 00:05: Plug and Play ACPI device, IDs WACf004 (disabled)



BUT

Code: Select all


root@X200 ~ # pidof inputattach                                                                                                                     
root@X200 ~ # pidof isdv4-serial-inputattach                                                                                                             
842                                                                                                                                                           
root@X200 ~ #                           


This apparently gets run at ~11 seconds right before xorg kicks in.

Something, somewhere, picks up the WACf004 device and runs isdv4-serial-inputattach (with the right serial port no less), which adds it to the input subsystem, and then xorg automagically picks it up when it starts.. So no udev involved, at all.
the functional script doesn't seem to live in /etc...

Still digging. I suppose xorg might call it itself but haven't found the calling script or binary. Yet.

/proc/842/status shows PID1 to be its caller, so that narrows it down to the largely inscrutable systemd.

[JMiahMan]

In mint udev rules (last I knew) where in /etc/udev/rules.d (Debian Squeeze was /etc/udev/rules.d/70-wacom-serial.rules)
do know it could be in multiple places now..
/etc/udev/rules.d
/lib/udev/rules.d
/run/udev/rules.d
/var/run/udev/rules.d

I bet you will find a wacom rule in there, somewhere..

https://bugs.mageia.org/show_bug.cgi?id=21238

[waferhead]

Ah.

Its launched by systemd working on chain...

Systemd is calling isdv4-serial-inputattach, which adds the input devices. xorg can then pick it up.
udev is not involved on Mint anymore, at least for the wacom device.

I'm not sure what is being triggered where, but its an ACPI device, and something in systemd knows what to do with it.
It isn't udev anymore.

Still poking around....

[JMiahMan]

It still is for Mageia.. the needed systemd service and udev rule are being excluded in the xorg-x11-drv-wacom package from a commit about 3 years ago (I posted it above) and 2 years ago there was a similar bug filed to your issue that was never fixed. Also Fedora is still using the udev rule and systemd method and I would argue they're pretty on top of things with hardware (that have open drivers). So I wonder if you have counted udev (now a part of systemd) rules out too early.. udev loads pre pivot in the init.. with dracut now.. so it would be pretty early in the process. I'll download mint and check out their udev/systemd install. Also take note, just because it's registered with ACPI does not mean a kernel module is loaded.. or that one even exists for that particular hardware. It just means ACPI sees the hardware, the BIOS or EFI knows about the hardware, but it's all in the handoff to the kernel, and the hardware abstraction layer (hal/udev).

[waferhead]

It still is for Mageia.. the needed systemd service and udev rule are being excluded in the xorg-x11-drv-wacom package from a commit about 3 years ago (I posted it above) and 2 years ago there was a similar bug filed to your issue that was never fixed. Also Fedora is still using the udev rule and systemd method and I would argue they're pretty on top of things with hardware (that have open drivers). So I wonder if you have counted udev (now a part of systemd) rules out too early.. udev loads pre pivot in the init.. with dracut now.. so it would be pretty early in the process.

It IS using udevd, but it doesn't show up in udev debug...
systemd is loading the rule which directly launches inputattach, which fails, but a service is apparently started, which then launches isdv4-serial-inputattach, which succeeds. The latter checks both baudrates, inputattach defaults to 38400.(but can actually do many other devices as well as the wacom w8001)

font color apparently doesnt work in code blocks.

Code: Select all

Jul 13 22:28:14 X200 systemd-udevd[390]: Reading rules file: /lib/udev/rules.d/60-inputattach.rules
Jul 13 22:28:14 X200 systemd-udevd[390]: Reading rules file: /lib/udev/rules.d/60-libgphoto2-6.rules
Jul 13 22:28:14 X200 systemd-udevd[390]: Reading rules file: /lib/udev/rules.d/60-libsane.rules
Jul 13 22:28:14 X200 systemd-udevd[390]: Reading rules file: /lib/udev/rules.d/60-openobex.rules
Jul 13 22:28:14 X200 systemd-udevd[390]: Reading rules file: /lib/udev/rules.d/60-pcmcia.rules
Jul 13 22:28:14 X200 systemd-udevd[390]: Reading rules file: /lib/udev/rules.d/60-persistent-alsa.rules
Jul 13 22:28:14 X200 systemd-udevd[390]: Reading rules file: /lib/udev/rules.d/60-persistent-input.rules


snipped for brevity

Code: Select all

Jul 13 22:28:15 X200 systemd[1]: wacom-inputattach@ttyS4.service: Trying to enqueue job wacom-inputattach@ttyS4.service/start/fail
Jul 13 22:28:15 X200 systemd[1]: systemd-timesyncd.service: Merged into installed job systemd-timesyncd.service/start as 57
Jul 13 22:28:15 X200 systemd[1]: systemd-hwdb-update.service: Installed new job systemd-hwdb-update.service/start as 181
Jul 13 22:28:15 X200 systemd[1]: home.mount: Merged into installed job home.mount/start as 23
Jul 13 22:28:15 X200 systemd[1]: console-setup.service: Merged into installed job console-setup.service/start as 34
Jul 13 22:28:15 X200 systemd[1]: systemd-machine-id-commit.service: Merged into installed job systemd-machine-id-commit.service/start as 43
Jul 13 22:28:15 X200 systemd[1]: network-pre.target: Merged into installed job network-pre.target/start as 54
Jul 13 22:28:15 X200 systemd[1]: plymouth-read-write.service: Merged into installed job plymouth-read-write.service/start as 10
Jul 13 22:28:15 X200 systemd[1]: friendly-recovery.service: Installed new job friendly-recovery.service/start as 229
Jul 13 22:28:15 X200 systemd[1]: media-win_x.mount: Merged into installed job media-win_x.mount/start as 29
Jul 13 22:28:15 X200 systemd[1]: systemd-fsck@dev-disk-by\x2duuid-2f18bc33\x2d0a13\x2d48cf\x2da089\x2df1689028db32.service: Merged into installed job systemd-fsck@dev-disk-by\x2duu
Jul 13 22:28:15 X200 systemd[1]: systemd-update-utmp.service: Merged into installed job systemd-update-utmp.service/start as 115
Jul 13 22:28:15 X200 systemd[1]: systemd-binfmt.service: Installed new job systemd-binfmt.service/start as 191
Jul 13 22:28:15 X200 systemd[1]: plymouth-start.service: Installed new job plymouth-start.service/start as 245
Jul 13 22:28:15 X200 systemd[1]: setvtrgb.service: Merged into installed job setvtrgb.service/start as 47
Jul 13 22:28:15 X200 systemd[1]: sysinit.target: Merged into installed job sysinit.target/start as 7
Jul 13 22:28:15 X200 systemd[1]: systemd-ask-password-console.path: Installed new job systemd-ask-password-console.path/start as 183
Jul 13 22:28:15 X200 systemd[1]: resolvconf.service: Merged into installed job resolvconf.service/start as 52
Jul 13 22:28:15 X200 systemd[1]: systemd-fsck-root.service: Installed new job systemd-fsck-root.service/start as 215
Jul 13 22:28:15 X200 systemd[1]: time-sync.target: Merged into installed job time-sync.target/start as 58
Jul 13 22:28:15 X200 systemd[1]: local-fs.target: Merged into installed job local-fs.target/start as 22
[color=#FF0000]Jul 13 22:28:15 X200 systemd[1]: wacom-inputattach@ttyS4.service: Installed new job wacom-inputattach@ttyS4.service/start as 175[/color]
Jul 13 22:28:15 X200 systemd[1]: sys-kernel-config.mount: Installed new job sys-kernel-config.mount/start as 220
Jul 13 22:28:15 X200 systemd[1]: systemd-tmpfiles-setup.service: Merged into installed job systemd-tmpfiles-setup.service/start as 64
[color=#FF0000]Jul 13 22:28:15 X200 systemd[1]: system-wacom\x2dinputattach.slice: Installed new job system-wacom\x2dinputattach.slice/start as 176[/color]
Jul 13 22:28:15 X200 systemd[1]: brltty.service: Installed new job brltty.service/start as 247
[color=#FF0000]Jul 13 22:28:15 X200 systemd[1]: wacom-inputattach@ttyS4.service: Enqueued job wacom-inputattach@ttyS4.service/start as 175[/color]
Jul 13 22:28:15 X200 systemd[1]: brltty.service: About to execute: /bin/sh -c 'grep -sq '^ *RUN_BRLTTY=no' /etc/default/brltty || exec /sbin/brltty -P /run/brltty.pid'
Jul 13 22:28:15 X200 systemd[1]: brltty.service: Forked /bin/sh as 615
Jul 13 22:28:15 X200 systemd[1]: brltty.service: Changed dead -> running
Jul 13 22:28:15 X200 systemd[1]: brltty.service: Job brltty.service/start finished, result=done
Jul 13 22:28:15 X200 systemd[1]: Started Braille Device Support.
[color=#FF0000]Jul 13 22:28:15 X200 systemd[1]: system-wacom\x2dinputattach.slice changed dead -> active
Jul 13 22:28:15 X200 systemd[1]: system-wacom\x2dinputattach.slice: Job system-wacom\x2dinputattach.slice/start finished, result=done
Jul 13 22:28:15 X200 systemd[1]: Created slice system-wacom\x2dinputattach.slice.[/color]


But that doesn't actually load the input devices, so it must start:

Code: Select all

[color=#FF0000]Jul 13 22:28:16 X200 systemd[1]: wacom-inputattach@ttyS4.service: About to execute: /usr/bin/isdv4-serial-inputattach /dev/ttyS4
Jul 13 22:28:16 X200 systemd[1]: wacom-inputattach@ttyS4.service: Forked /usr/bin/isdv4-serial-inputattach as 842[/color]
Jul 13 22:28:16 X200 systemd[841]: accounts-daemon.service: Executing: /usr/lib/accountsservice/accounts-daemon
[color=#FF0000]Jul 13 22:28:16 X200 systemd[1]: wacom-inputattach@ttyS4.service: Changed dead -> running
Jul 13 22:28:16 X200 systemd[1]: wacom-inputattach@ttyS4.service: Job wacom-inputattach@ttyS4.service/start finished, result=done
Jul 13 22:28:16 X200 systemd[1]: Started inputattach for Wacom ISDv4-compatible serial devices.
Jul 13 22:28:16 X200 systemd[842]: wacom-inputattach@ttyS4.service: Executing: /usr/bin/isdv4-serial-inputattach /dev/ttyS4[/color]


The input devices now exist at this point, dev/ttyS4 seems to either be an alias or its mapped different on Debian-ish kernels.

Code: Select all

Jul 13 22:28:17 X200 kernel: input: Wacom Serial Penabled 1FG Touchscreen Pen as /devices/pnp0/00:05/tty/ttyS4/serio2/input/input13
Jul 13 22:28:17 X200 kernel: input: Wacom Serial Penabled 1FG Touchscreen Finger as /devices/pnp0/00:05/tty/ttyS4/serio2/input/input14




[JMiahMan]

udev, the hardware abstraction layer has been sucked in by Systemd.. do to what I like to call Lennart Creep. So yes when you see systemd-udev.. that was what was once called udev.. There's a service for systemd that when udev sees the wacom (serial) hardware it runs.. Depending on the distro and how they are doing their rules there will be different file names but they all pretty much have the same syntax.

In this case mint (this is old but it's similar) is calling the 60-inputattach.rules
which contains what's in the below..
lib/udev/rules.d/60-inputattach.rules

Code: Select all

# Attach Wacom W8001 devices
SUBSYSTEM=="tty", KERNEL=="ttyS[0-9]*", ATTRS{id}=="FUJ02e5", ACTION=="add|change", RUN+="/usr/bin/inputattach --daemon --baud 19200 --w8001 /dev/%k"
SUBSYSTEM=="tty", KERNEL=="ttyS[0-9]*", ATTRS{id}=="WACf00c", ACTION=="add|change", RUN+="/usr/bin/inputattach --daemon --baud 38400 --w8001 /dev/%k"


The above example actually doesn't rely on the systemd service but rather does it's own call (which I rather prefer because then you can run OpenRC or another init system and the rule still works)

On Redhat based systems it's the /lib/udev/rules.d/70-wacom.rules

Code: Select all

ACTION!="add|change", GOTO="wacom_end"

# Match all serial wacom tablets with a serial ID starting with WACf
# Notes: We assign NAME though we shouldn't, but currently the server requires it
#        We assign the lot to subsystem pnp too because server reads NAME from
#        the parent device. Once all that's fixed, as simple SUBSYSTEM="tty"
#        will do and the ENV{NAME} can be removed.
SUBSYSTEM=="tty|pnp", SUBSYSTEMS=="pnp", ATTRS{id}=="WACf*", ENV{ID_MODEL}="Serial Wacom Tablet $attr{id}", ENV{ID_INPUT}="1", ENV{ID_INPUT_TABLET}="1", ENV{NAME}="Serial Wacom Tablet $attr{id}"
SUBSYSTEM=="tty|pnp", SUBSYSTEMS=="pnp", ATTRS{id}=="FUJ*", ENV{ID_MODEL}="Serial Wacom Tablet $attr{id}", ENV{ID_INPUT}="1", ENV{ID_INPUT_TABLET}="1", ENV{NAME}="Serial Wacom Tablet $attr{id}"

# comment out the next line if your distribution does not provide systemd
# If a /dev/ttySx device with the WACf name is detected, start the
# wacom-inputattach service with the kernel name as parameter
SUBSYSTEM=="tty|pnp", KERNEL=="ttyS[0-9]*", ATTRS{id}=="WACf*", TAG+="systemd", ENV{SYSTEMD_WANTS}+="wacom-inputattach@%k.service"

LABEL="wacom_end"


See the similarities? My point is Mageia is missing some form of this udev rule (that's supplied by the aforementioned package).. that's why you have to call it manually

Just for fun here's the Systemd service that udev calls
/lib/systemd/system/wacom-inputattach@.service

Code: Select all

[Unit]
Description=inputattach for Wacom ISDv4-compatible serial devices

[Service]
Type=simple
ExecStart=/usr/bin/isdv4-serial-inputattach /dev/%I
Restart=on-success

[waferhead]

Gotcha.
SHOULD be provided by that package, but isn't due to (some reason lost in the mists of time)
It's been missing since ~Mageia 2, possibly longer, as that just happens to be when I got this machine.

The manual rule additions I have been using since then did the deed until mga6... the xorg driver and the kde control panel wacom item etc have always worked once the rules were added.

How exactly would I even report this bug?.
simply as a missing udev rule?
(I'll copy it over and see it it Just Works, terminal optimist here)

There's more stuff missing, apparently, I'll try the Fedora rule

[JMiahMan]

It's already been reported... today.. by me when I figured this all out earlier in the day.
https://bugs.mageia.org/show_bug.cgi?id=21238

Please watch the ticket as it seems serial wacom users only come around every few years..

interesting enough that is what most likely cause this bug as well..
https://bugs.mageia.org/show_bug.cgi?id=15787

I bet if he would of installed the 0.26.1 version from source it would have worked as well because from source you would get the needed files (as the rpm package has them excluded).

BTW if you love Mageia to pieces and promise to use it for a while I'll build you a custom rpm to fix this.. PM me if you're interested.. or just wait.

[waferhead]

Cool.

The redhat version of the rule alone just hangs the startup, will stick with the workaround until the package is updated.

[JMiahMan]

As root try (copy and paste)

Code: Select all

cat <<'EOF' >>  /lib/udev/rules.d/70-wacom.rules
ACTION!="add|change", GOTO="wacom_end"

# Match all serial wacom tablets with a serial ID starting with WACf
# Notes: We assign NAME though we shouldn't, but currently the server requires it
#        We assign the lot to subsystem pnp too because server reads NAME from
#        the parent device. Once all that's fixed, as simple SUBSYSTEM="tty"
#        will do and the ENV{NAME} can be removed.
SUBSYSTEM=="tty|pnp", SUBSYSTEMS=="pnp", ATTRS{id}=="WACf*", ENV{ID_MODEL}="Serial Wacom Tablet $attr{id}", ENV{ID_INPUT}="1", ENV{ID_INPUT_TABLET}="1", ENV{NAME}="Serial Wacom Tablet $attr{id}"
SUBSYSTEM=="tty|pnp", SUBSYSTEMS=="pnp", ATTRS{id}=="FUJ*", ENV{ID_MODEL}="Serial Wacom Tablet $attr{id}", ENV{ID_INPUT}="1", ENV{ID_INPUT_TABLET}="1", ENV{NAME}="Serial Wacom Tablet $attr{id}"

# comment out the next line if your distribution does not provide systemd
# If a /dev/ttySx device with the WACf name is detected, start the
# wacom-inputattach service with the kernel name as parameter
SUBSYSTEM=="tty|pnp", KERNEL=="ttyS[0-9]*", ATTRS{id}=="WACf*", TAG+="systemd", ENV{SYSTEMD_WANTS}+="wacom-inputattach@%k.service"

LABEL="wacom_end"
EOF

and...

Code: Select all

cat <<'EOL' >> /lib/systemd/system/wacom-inputattach@.service
[Unit]
Description=inputattach for Wacom ISDv4-compatible serial devices

[Service]
Type=simple
ExecStart=/usr/bin/isdv4-serial-inputattach /dev/%I
Restart=on-success
EOL

remove your one liner from rc.local, reboot and see if it works.

[waferhead]

There's an extraneous "cat..." line in both files I missed, commented both out, locks up again.
Tried naming wacom-inputattach@.service and wacom-inputattach.service

Still locks solid right after ip6_tables starts, when xorg should be starting.


Somethings still missing, was there a change to the wacom driver rules in xorg?
(some sort of conflict...read it somewhere)

BTW if you love Mageia to pieces and promise to use it for a while I'll build you a custom rpm to fix this.. PM me if you're interested.. or just wait.

I've been using "Mageia" since Mandrake Linux was just a brand new fork of redhat (7?) with 586 optimisations.
I'll merrily test the fixed rpm.

I just happen to have Mint loaded on a spare partition for testing after cooker got ~stable.
Its like ubuntu with some of the stupid buffed off...

I also have Android-x86 (several versions) and Arch, as well as Win 10 on this thing, but Mageia is default, despite a few warts.

Does openrc work on mga6? Systemd gives me a migraine.
Ripping it out by the roots would bring great joy to many.

[JMiahMan]

If you copy and pasted both to a console window and hit enter there shouldn't be any cat in there.. but if you vi'd nano'd or what have you, the file and path and then copied that in you would not only have the top cat line but also the EOL and EOF lines at the bottom that could be causing issues as well so check that out. I was trying to make it as easy as possible 😀

The problem with OpenRC is that It's an init wrapper. It offers a lot of the things you want from an init.. a lot of the things that Systemd has that made it look awesome compared to SysV, but it needs an init.. so in the past I have used busybox or even SysV and then had OpenRC manage all the init files.

The underlying problem is once you adopt Systemd it's so obtrusive that unless you have packaged and planned from the toolchain up to allow for different options then you end up with everything pretty much depending on it. I mean it's even used in dracut, the init or bootstrap os. The fact they have sucked in udev (there is a Gentoo fork called eudev) is crazy. Having so many eggs in one basket undermines the Unix ideology, though it seems there's not much of it left anyway. I think if Lennart could add the kernel under the umbrella of Systemd he would. From what I understand he's a nice guy (from my interactions with him it's hard to believe) and wants a unifying experience for Linux.. which sounds good, but what are/have the distros sacrificed to get there?

[waferhead]

Got it working with a bit more editing to rid a stray EOF marker.

That copy paste bit doesn't work with bash running in konsole as root.

For those wishing to copy/paste into an editor:
file 1 of 2: /lib/udev/rules.d/70-wacom.rules

Code: Select all

#/lib/udev/rules.d/70-wacom.rules
    ACTION!="add|change", GOTO="wacom_end"

    # Match all serial wacom tablets with a serial ID starting with WACf
    # Notes: We assign NAME though we shouldn't, but currently the server requires it
    #        We assign the lot to subsystem pnp too because server reads NAME from
    #        the parent device. Once all that's fixed, as simple SUBSYSTEM="tty"
    #        will do and the ENV{NAME} can be removed.
    SUBSYSTEM=="tty|pnp", SUBSYSTEMS=="pnp", ATTRS{id}=="WACf*", ENV{ID_MODEL}="Serial Wacom Tablet $attr{id}", ENV{ID_INPUT}="1", ENV{ID_INPUT_TABLET}="1", ENV{NAME}="Serial Wacom Tablet $attr{id}"
    SUBSYSTEM=="tty|pnp", SUBSYSTEMS=="pnp", ATTRS{id}=="FUJ*", ENV{ID_MODEL}="Serial Wacom Tablet $attr{id}", ENV{ID_INPUT}="1", ENV{ID_INPUT_TABLET}="1", ENV{NAME}="Serial Wacom Tablet $attr{id}"

    # comment out the next line if your distribution does not provide systemd
    # If a /dev/ttySx device with the WACf name is detected, start the
    # wacom-inputattach service with the kernel name as parameter
    SUBSYSTEM=="tty|pnp", KERNEL=="ttyS[0-9]*", ATTRS{id}=="WACf*", TAG+="systemd", ENV{SYSTEMD_WANTS}+="wacom-inputattach@%k.service"

    LABEL="wacom_end"


file 2 of 2:
/lib/systemd/system/wacom-inputattach@.service

Code: Select all

[Unit]
    Description=inputattach for Wacom ISDv4-compatible serial devices

    [Service]
    Type=simple
    ExecStart=/usr/bin/isdv4-serial-inputattach /dev/%I
    Restart=on-success


[JMiahMan]

Got it working with a bit more editing to rid a stray EOF marker.

That copy paste bit doesn't work with bash running in konsole as root.

Strange? Sorry about that, but I am glad you got it working.. now we just have to find out why they were not including those files in the rpm and if the reason is no longer valid rebuild the rpm with the excludes removed. I am now a packaging apprentice so hopefully that means I can help fix it.. I have an old Toshiba m200 that uses serial wacom and I am wondering if this will help it.. but it only has 512M of ram so I am scared to even test. I am liking the specs on your Lenovo X200t.. thinking about buying one off newegg just for fun. I like having around troublesome hardware in case things regress.

[waferhead]

The later versions have multitouch as well as the pen, and actually make for great tablets.
An X220 might be a bit better choice and can be had for about the same price.
Full size screen as well.
You want the large battery (8 or 9 cell, forget) as it doubles as an excellent handle in tablet mode.

I have intentionally run various distros/DEs with restricted memory (can be done in grub etc) to see if they bog down or get crashy...
Most preform nicely down to ~128M, esp if you have swap on an SSD. An SSD is like bolting a blower on an older (but decent) laptop, it will feel ~like a new machine. You can't install with that much memory in some case tho.

I have an old pentium M itronix gobook3, admittedly has 2gb memory, but it runs plasma desktop just fine on 512m (have several).. with a usata ssd in it on a converter replacing the old 5400 rpm toshiba IDE low power drive, it feels almost fast./