HOW TO: Install a LinuxWacom Kernel Driver for Tablet PC's

[gali98]

I know as much about hal as you do :\
I'm not sure exactly what you're aiming at.. but your assumptions look right about the rules file.
Just so you know, rec's script does work!
Right now I'm just working out the kinks. Two sets of devices are still being created (and it has absolutely nothing to do with the rules file. I removed every wacom rules file and multiple sets are still being created. )
Maybe it has something to do with there being two events? (one for stylus/eraser and one for touch) Maybe we need to do something like you said with the two fdi files..
I'll look more into it.
Kory

[Favux]

Hi Kory,

Right. That was my initial guess to explain the duplicates. That the dBUS callout was seeing both of our input paths. And using the wacom strings query it was ending up with stylus, eraser, and touch on each path. Hence two .fdi files. So I'm aiming at correctly handling that. And possibly if they fix the callout to label things properly (or whatever they need to do to get the names correct) rec's script will be rendered redundant. And we're back to getting the .fdi file to work.

Great news! I am excited. I can't wait to you work out the kinks and report back.

[Favux]

Hi Everyone,

Roger E Critchlow Jr. (rec) originally posted his script in post #21 on the "Re: wacom-tools 1:0.8.2.2-0ubuntu2 busted" thread in the closed "Jaunty Jackalope Testing and Discussion" forum. It translates the HAL/D-BUS names the info.callout in the 10-wacom.fdi file is returning. For rec these were 'PnP Device (WACf008 )', 'PnP Device (WACf008 ) touch', and 'PnP Device (WACf008 ) eraser', back to Wacom names so linuxwacom recognizes them. I added some instructions to rec's script and renamed it to "wacom-names". Rec called it "wacom" and gali98 called it "wacomtohal".

Download the attached "wacom-names" script to your Desktop. Open the script into gedit. To install the script type in a terminal:

gksudo gedit /etc/init.d/wacom-names

Copy and paste the script into the empty file. Save and close. To make the script executable:

sudo chmod +x /etc/init.d/wacom-names

Before you do the next step be very sure the script is now present in "/etc/init.d/". I suggest navigating there with Nautilus (Places) and verifying the file "wacom-names" is present. Open it up with gedit and verify the script is in the file. You can also check with properties to verify "wacom-names" is executable.

To link the script to the appropriate run-levels (2 3 4 5):

sudo update-rc.d wacom-names defaults 27

or you could use:

sudo update-rc.d wacom-names start 27 2 3 4 5 .

Starting it at 27 (S27) causes it to run after HAL is started and before Xserver starts. Reboot. Typing "xsetwacom list" in a terminal should now return Wacom names such as stylus, eraser, etc. and wacomcpl and xsetwacom commands should work. To calibrate and configure your tablet with wacomcpl go to Section 3 on page 1 post #1 of this thread.

To remove the script type the following in a terminal:

sudo update-rc.d -f wacom-names remove

And then to complete the removal of the script type:

sudo rm /etc/init.d/wacom-names

Attached is rec's script renamed "wacom-names".

[gali98]

Actually no...
Here is what My script looks like:

#! /bin/sh
## find any wacom devices
for udi in `hal-find-by-property --key input.x11_driver --string wacom`
do
type=`hal-get-property --udi $udi --key input.x11_options.Type`
## rewrite the names that the Xserver will use
hal-set-property --udi $udi --key info.product --string $type
done

That first line is necessary for the script to run. (It also needs to be executable - chmod +x file)

That

case $type in
    stylus|eraser)
# map stylus button 2 to mouse button 3
hal-set-property --udi $udi --key input.x11_options.Button2 --string 3
;;
esac

part was actually for changing the button. The whole thing. I took that whole part out. My script is the most basic it can get.
Kory

[Favux]

Hi gali98,

Wow, what was I thinking? Obviously I wasn't. Thanks.

Do I have it right now?

In terms of getting HAL to log:

One useful tip is that hald's --use-syslog option isn't documented in the Debian man page, and without it you can't see anything that hald is up to. (I've submitted a bug about this.) Update: As the message from hald --help suggests, --use-syslog only works if you also have --verbose=yes.

To get detailed information on your logs, ask hald to be verbose changing your /etc/conf.d/hald to HALD_VERBOSE="yes"

And from man hald:
--use-syslog
Enable logging of debug output to the syslog instead of stderr.
Use this option only together with --verbose.

[gali98]

Yep that looks good..
I'll work on the hal thing later.. Got too much stupid homework.
Thanks for the info though.. I couldn't find anything.
Kory

[Favux]

Hi everyone,

From the HAL 0.5.10 Spec. here: http://people.freedesktop.org/~david...properties-usb These seem to be the available options.


For device objects representing USB devices the property info.subsystem will be usb_device, and the following properties will be available. Note that the corresponding USB interfaces are represented by separate device objects as children.

usb_device namespace
usb_device.linux.sysfs_path (string)
usb_device.product_id (int)
usb_device.vendor_id (int)
usb_device.device_revision_bcd (int)
usb_device.serial (string)
usb_device.product (string)
usb_device.vendor (string)


Device objects that represent USB interfaces, ie. when info.subsystem assumes usb, are represented by the properties below. In addition all the usb_device.* properties from the parent USB device is available in this namespace but only with the usb prefix instead of usb_device.

usb namespace
usb.interface.description (int)
usb.interface.number (int)
usb.linux.sysfs_path (string)

The "usb_device.linux.sysfs_path" seems a likely candidate since it seems to rely on the same pci input path we use in xorg.conf. The example they give is: /sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1.1/1-1.1:1.0 . And they also say it's equivalent to "linux.sysfs_path".

Another possibility would be "usb_device.serial", but that seems less likely. Especially since they say serial number is broken on some USB devices. It's not clear that stylus and touch would be considered separate instances of the device.

So it may be possible to separate the stylus and touch .fdi files the same way as we do in xorg.conf. I've gone through this stuff some. I looked through the "lshal" output and it looks like "linux.sysfs_path" does distinguish between stylus and touch. They are both labeled "stylus" but I'm hoping that's due to the Intrepid 10-wacom.fdi only having "stylus". I doubt the attached .fdi files will work, but they may vaguely look like ones that would work. And of course they would only work for the TX2000. We'd need the paths for the TX2500 to get working .fdi's for it. So not a very elegant method. But then they're the only two tablet pc's that I know of that need it.

[gali98]

Sounds like a good idea. I will test it when I get home. I'll let you know how it works out.
Kory

Edit:
and We might still try the usb_device.serial. It may work with the wacom devices...

[isacvale]

I'm so so sorry if I'm disrupting the topic, but you've lost me. You might think I've not been reading because of my question but i have - i just have not been understanding.

I'm a complete end user - been creating graphics in ubuntu for years but never did actually had to learn shell script ou compiling or fixing bugs or what a fdi is (wich goes to prove ubuntu really IS for regular human beings).

Now, I've acquired a tx2623 (2500 series), and installed jaunty, as i've inferred from some forums it would be easier to get the tablet working. The first post on this thread sent me to post 65, which, basically says the if you're on jaunty and get the timo's package from synaptic, it should just work.

Problem is it didn't. At all. After a couple of (many) hours, i just tried to compile as post 1 explains. It was easy to follow - a perfect tutorial - but when it came to editing xorg.conf, it didn't help. It crashed when loading ubuntu, as with all other xorg.conf modifications i've seen so far (and it's very hard to get all things back to normal when you don't know shell script).

Now that I've told my life story, I ask that, if you don't mind, redo a post 65 explaining how to get wacom working on a jaunty tx2500. Something noob-friendly as post 1, but that will not crash ubuntu.

Thank you either you can help me or not (for listening to the whining).

[Favux]

Hi isacvale,

As you've discovered Timo's patched linuxwacom 0.8.2-2 in Jaunty has problems. What's happening is that when the call out is made in the 10-wacom.fdi (fdi=device information file) D-BUS (desktop-bus) is returning the usb names for your tablet devices but the names are not the same as linuxwacom uses. That's the problem. You are probably missing that because of lack of context. On this thread rec discovers there is a problem, investigates it and solves it: http://ubuntuforums.org/showthread.php?t=1122952 You probably missed the link and that's why things don't make sense. His script is also in post #93 above (instructions included). With it translating the D-BUS/HAL terms into Wacom names wacomcpl etc. start working. So you can get the "native" Jaunty method working now. We are still ironing out some kinks though. As you know the TX2000 and the TX2500 actually have two devices: the Wacom digitizer and the touchscreen.

What may have happened when you compiled 0.8.3-2 is that you forgot to go into Synaptics Package Manager and remove the file "libhal1-dev" so you got hal features into your compiled driver, ending up in the same place as you were with Timo's drivers. And that's why X breaks when you boot with Wacom stuff in your xorg.conf.

Hi Kory,

I forgot to mention that when I:

hal-find-by-property --key input.x11_driver --string wacom

I get two uid's:

/org/freedesktop/Hal/devices/usb_device_56a_93_noserial_if1_logicaldev_input
/org/freedesktop/Hal/devices/usb_device_56a_93_noserial_if0_logicaldev_input

So I'm guessing that's why there are 5 Wacom sections on lshal. The parent and two pairs of daughters each pair with a uid. I'm not really seeing any other differentiation.

hal-find-by-property --key usb_device.serial --string wacom

Does not return anything. And to confirm it usb_device.serial isn't in the lshal output for the parent or daughters.