HOW TO Set Up a Wacom Serial Tablet in Ubuntu

[Favux]

Thanks for all your work. I figured I just misunderstood you. Deutsch?

Looks like you are doing everything correctly which probably means I am the one doing something wrong.

The fact that even MatchDevicePath "/dev/ttyS0" alone doesn't work is probably a big fat clue if I can figure it out.

I have v2 back up for you to test. Compiles without the error anyway.

Sleep well. Tomorrow then.

[dreh]

hehe and
compiled --> installed --> (v2 repaired) works!
Im off to bed.
J.

[Favux]

Outstanding! Thank you for testing it.

lol You couldn't leave it alone either.


Regarding the snippet. Have you tried?

Section "InputClass"
    Identifier "Wacom legacy serial class"
    MatchPnPID "PNP0501"
    Driver "wacom"
    Option "ForceDevice" "Serial"
EndSection

[dreh]

Outstanding! Thank you for testing it.

lol You couldn't leave it alone either.


Regarding the snippet. Have you tried?

Section "InputClass"
    Identifier "Wacom legacy serial class"
    MatchPnPID "PNP0501"
    Driver "wacom"
    Option "ForceDevice" "Serial"
EndSection

morning,
i tried the above snippet (again) and couldn't get it run.

Unfortunately we maybe introduced a bug: In Gimp when I draw with the tablet the pressure curve works like intended till you force the pen quite hard on the tablet (I would say it's max pressure). If I do that the stroke stops drawing until I loosen it a bit again than it continuous. So Max pressure = 0 ClickForce. Is there a possibility to calibrate this with xsetwacom or Gimp preferences? I'll try another painting program.
I'll update more on this ... Probably it would be good to test 10.6 and 10.7 v1 if the bug is here, too.
J.

Edit: Same behavior in Inkscape

[Favux]

i tried the above snippet (again) and couldn't get it run.

Shoot. I would really like a snippet for v3. I guess the last thing to try is:

Section "InputClass"
    Identifier "Wacom legacy serial class"
    MatchProduct "PNP0501"
    Driver "wacom"
    Option "ForceDevice" "Serial"
EndSection

because I can't imagine MatchVendor would work. What I'm thinking is MatchDevicePath only works on the input subsystem. In other words the path has to be /dev/input/something which is why /dev/ttyS0 isn't working. The documentation (what little there is) doesn't say that, but it is the only thing that makes sense.

For a lark you could try MatchDevice "/dev/ttyS0" as the only match. I thought I read that one somewhere but I can't find it now. The only new match I'm sure they added was MatchDriver for Xserver 1.10. If you try MatchDevice be sure to back up your current working 50-wacom.conf so you can restore it if MatchDevice breaks X. I guess I'll have to try and find the .fdi we were using in HAL. But I don't think there is a direct translation from that match to a xorg.conf.d Match.

Unfortunately we maybe introduced a bug: In Gimp when I draw with the tablet the pressure curve works like intended till you force the pen quite hard on the tablet (I would say it's max pressure). If I do that the stroke stops drawing until I loosen it a bit again than it continuous. So Max pressure = 0 ClickForce.

What Mode is your tablet in, Relative or Absolute? The pressure fix for 0.10.7 was:

In relative mode, subtract the old pressure value from the new one.

Otherwise the pressure builds up to the maximum and stays there, even when the pen is lifted off the tablet. Same goes for tilt, wheel and rotation/throttle

Sure you can adjust ClickForce. The default is 27. At some point they normalized all pressure levels to 0 - 2047 regardless of what the hardware reports. So I think you could increase ClickForce all the way to 2047 if you wanted.

xsetwacom set "stylus" ClickForce "54"

The bug could be from the serial code but it is at least as likely to be in the driver code. The 0.10.x series was not suppose to be for general user use. That is the code cleanup and feature subtract and add series tree. 0.11.0, which just came out, was suppose to be the first version for general user testing. Because it is suppose to be nearly feature complete and more bug free. In other words more stable code.

So definitely:

Probably it would be good to test 10.6 and 10.7 v1 if the bug is here, too.

Maybe timonoko or someone else could tell us if they are seeing it with 0.10.6? Or in Lucid in case it is a Maverick thing.


Edit: Oh, and did I guess correctly? Your Digitizer II is a UD-0608-A?

[tokenrove]

So even if after 0.10.8 it is smooth sailing to 0.11.1 that would likely be a problem for submission of the patch set. Not to mention the error messages need to be fixed and the requested look up tables, etc. Of course tokenrove may by then have code that obviates those problems.

I think the old approach of having all the serial code in the xorg driver is probably not the right direction. I now have a working input driver for protocol 4 Wacom serial tablets -- at least it works nicely on my Digitizer II; I still need to do some debugging and put protocol documentation up on the xf86-input-wacom wiki, but it's a good step. It works just fine with the existing wcmUSB code on the X side.

This brings me to a question (obviously I'll ask the linuxwacom-devel list, too, but I wanted to get a general feel here first) -- are many people using serial Intuos or Intuos 2 tablets? I don't have any protocol 5 devices and I think things would be cleaner if the drivers were separate.

[Favux]

Hi tokenrove,

I think the old approach of having all the serial code in the xorg driver is probably not the right direction.

Sure, but while we're waiting for you to come up with the code I thought I'd see what we could do with what we have. Actually making some progress.

I now have a working input driver for protocol 4 Wacom serial tablets -- at least it works nicely on my Digitizer II; I still need to do some debugging and put protocol documentation up on the xf86-input-wacom wiki, but it's a good step. It works just fine with the existing wcmUSB code on the X side.

That is great! Real progress and fast too.

This brings me to a question (obviously I'll ask the linuxwacom-devel list, too, but I wanted to get a general feel here first) -- are many people using serial Intuos or Intuos 2 tablets? I don't have any protocol 5 devices and I think things would be cleaner if the drivers were separate.

Don't forget the Citiq's. Although having support for better than half the serial models is obviously better than no support.

[tokenrove]

That is great! Real progress and fast too.

Thanks. I would have liked to have gotten to it sooner but some other things got in the way. Anyway, I expect by the end of the evening I should be at the limits of what I can do with my tablet alone and will need others to test. (Already, my itch is scratched, since I can finally use my tablet in the gimp properly.)

Don't forget the Citiq's. Although having support for better than half the serial models is obviously better than no support.

According to the old serial code, the Cintiqs were protocol 4. Only the Intuos 1 and 2 are protocol 5, according to that code. I don't know if it's just that that code worked with the Cintiqs in some sort of backwards compatibility mode.

Anyway, I'm going to ask about that on the mailing list. I'd just like to know how much interest there is in having an Intuos driver and whether I should put together an implementation or if someone actually owning such a device is interested in doing it.

Cheers.

[Favux]

Hi Johannes,

I looked at the code a little and I see the pressure levels set in the model specific section of wcmSerial.c like the usb tablet pressure levels are specified for each model in the usb kernel driver wacom.ko's wacom_wac.c file. Then in the parse function section I see that the model specific pressure levels are used to help parse the incoming serial data packets. But I haven't seen anything that would actually manipulate pressure so I don't think the problem is in the serial patches. Just another reason to try and get the serial patches to build on 0.10.8 I guess.


Johannes and others interested in testing,

I have a release candidate for the version 3 patches. Because these patches are more likely to break things than anything previous I'll attach the 3 changed patches here. Just replace the corresponding v2 patch with the v3 patch. But keep the v2 patches! Then go ahead and compile as usual. Good luck!

[Favux]

I went over everything and the snippet I posted in #33 should work:

Section "InputClass"
    Identifier "Wacom legacy serial class"
    MatchPnPID "PNP0501"
    Driver "wacom"
    Option "ForceDevice" "Serial"
EndSection

Try changing "Serial" to "SERIAL" to check if it is case specific in xorg.conf.d. The line we were using in the wacom.fdi with HAL was:

<match key="@info.parent: pnp.id" contains_outof="PNP0501;WACf;FUJ02e5;FUJ02e7">

So you can see why I thought MatchProduct might work. But I found the commit for MatchPnPID and it explains why we need to use it instead: http://cgit.freedesktop.org/xorg/xse...57936b93326a2a

So as long as the command:

udevadm info -a -p $(udevadm info -q path -n /dev/ttyS0)

has the following section in the output:

looking at parent device '/devices/pnp0/00:08':
KERNELS=="00:08"
SUBSYSTEMS=="pnp"
DRIVERS=="serial"
ATTRS{id}=="PNP0501"

the snippet should work. As you can see it is the Plug n Play (pnp) subsystem and the Plug n Play ID or ATTRS{id} is "PNP0501". So if it isn't working check and see if "PNP0501" has disappeared from that section. It shouldn't do that though, which is what is making me wonder about SERIAL.