I don't know where to start from... I've Ubuntu 10.04 (Lucid Lynx), the 64-bit edition, and a Manhattan Graphics Tablet whose device ID is 5543:0005 and its internal name is "UC-LOGIC Tablet WP8060U". Some times with more difficulty than others, I was able to make it work in the past. The easiest time was with Ubuntu 9.10 (Karmic Koala). However I'm facing serious problems in the last version from Canonical.
I've tried both ways, installing the last package from the DoctorMo repositories and also compiling the sources from LaunchPad by myself. No luck with any of them.
What's the problem in a few words? The pen is perfectly recognized and I can move the pointer over any place on the screen. However, once that I press the tip for first time, it's like if the pointer got stuck and I needed to continue pressing the pointer to move it.
I've checked the logs from /var/log/Xorg.0.log and in one line it says:
(**) UC-LOGIC Tablet WP8060U: Applying InputClass "evdev pointer catchall"
I've seen in the logs from people who have successfully installed their tablets that there are 3 lines like this, being this the first one, and another one assigning the InputClass "wizardpen" the last one. I lack of that last line, which makes me think that the X server doesn't parse the 70-wizardpen.conf right. Or maybe it does it right but my tablet doesn't match its rules (what would be weird as it's just a simple WP8060U tablet and is perfectly set in the udev and HAL rules).
Another interesting test which I did was to edit /etc/X11/xorg.conf, which always seemed to work for me in the past, except when the X server started to rely on the HAL rules (FDI files). I added something like this:
Section "InputDevice"
Identifier "Tablet0"
Driver "wizardpen"
Option "Device" "/dev/input/event6"
Option "TopX" "2650"
Option "TopY" "3563"
Option "TopZ" "10
Option "BottomX" "30733"
Option "BottomY" "29715"
Option "BottomZ" "511"
EndSection
Result? ALMOST DONE! I could move the pen like before and when I pressed the tip I still was able to move it without pushing it again. What's wrong then? The fact that the pen seems to send 2 events to the X server when a button is pressed, like if 2 of them were pressed at the same time.
For example, if I click on a page while I'm using Firefox, apart of doing the actual click, it also turns me back to the past page in the history. I could confirm this executing "xev" and checking which kind of events it triggered, resulting in:
Tip => It triggers key codes 1 & 8 .
Button A => It triggers key codes 2 & 9 .
Button B => It triggers key codes 3 & 10 .
This means that when pressing a button, it causes 2 different actions. I tried to use xinput to alter this behaviour with no luck.
So, summarizing a lot, I get 2 different behaviours depending on if I edit /etc/X11/xorg.conf or not. And, by the way, if I don't edit this file, no mention to the driver "wizardpen" appears in the logs of X. Although it's not assigned to the tablet, at least it's mentioned as loaded.
By the way, I never got a soft link called /dev/tablet-event , that's why I had to use /dev/input/event6 instead.
Here it's the other log...