Fix for buggy aiptek-drivers

Bug #198599 reported by Steveway
10
Affects Status Importance Assigned to Milestone
xserver-xorg-input-aiptek (Ubuntu)
Fix Released
High
Steveway

Bug Description

Copy from my forum post:
Since the Aiptek-driver has finally been fixed and a new owner arrived, Hardy needs to ship the fixed version to be truely "Hardy".
The new Owner's name is, René van Paassen and he seemed to have fixed the driver, finally.
The version has been bumped to 1.1.1 and it should have fixed most bugs.
Tarballs are still only avaiable for the old broken version that still comes with Ubuntu (that version is from 2006!).
Hopefully the Ubuntu-devs make a new .deb soon and maybe they could add a script that checks lsusb for something like this:
Code:

Bus 001 Device 002: ID 08ca:0021 Aiptek International, Inc. APT-2 Tablet

(That's from my tablet.)
And then add the appropiate lines to the xorg.conf like in this how-to: http://ubuntuforums.org/showthread.php?t=122735&highlight=aiptek
I hope to see updates comming through soon.

(Link to the gitweb: http://gitweb.freedesktop.org/?p=xorg/driver/xf86-input-aiptek.git;a=summary )
I also request a feature-freeze exception for this, like 23meg said. Hopefully someone will pick it up soon, I'll try to help where I can.
Apperantly these things here are needed for a feature-freeze-exception:
Upstream changelog entries:

5 weeks agoBumped the version to 1.1.1 master / xf86-input-aiptek-1.1.1
René van Paassen [Tue, 29 Jan 2008 21:42:40 +0000]

Bumped the version to 1.1.1

This version is actually being tested/used by someone with a tablet (me)

5 weeks agoadded #if to handle MiPointer{Current|Get}Screen cases

René van Paassen [Tue, 29 Jan 2008 21:32:04 +0000]

added #if to handle MiPointer{Current|Get}Screen cases

5 weeks agomoved xf86AiptekClose after RemoveEnabled.., fixes crash VT switch

René van Paassen [Tue, 29 Jan 2008 21:29:41 +0000]

moved xf86AiptekClose after RemoveEnabled.., fixes crash VT switch

5 weeks agoConverted xf86msg into debug messages, to prevent filling the log

René van Paassen [Tue, 29 Jan 2008 21:24:34 +0000]

Converted xf86msg into debug messages, to prevent filling the log

7 weeks agoDon't worry about being core pointer if XInput API is > 0.

Peter Hutterer [Thu, 17 Jan 2008 06:51:38 +0000]

Don't worry about being core pointer if XInput API is > 0.

Server 1.4 and above let all devices be XI devices and the core devices are

virtual. So we don't have to worry about it in the driver.

This should make the code compatible with both 1.3 and 1.4.

7 weeks agoRevert "Driver's don't have to worry about being core pointers anymore."

Peter Hutterer [Thu, 17 Jan 2008 02:54:46 +0000]

Revert "Driver's don't have to worry about being core pointers anymore."

There's a better way of doing things. See next commit.

This reverts commit 66e0fbb24377ac14b9cf8a80a55253cff13d7913.

2 months agoRemove redefinition of NEED_XF86_TYPES.

Peter Hutterer [Thu, 10 Jan 2008 00:57:39 +0000]

Remove redefinition of NEED_XF86_TYPES.

2 months agomiPointerCurrentScreen is deprecated, miPointerGetScreen is all the rage now.

Peter Hutterer [Thu, 10 Jan 2008 00:56:49 +0000]

miPointerCurrentScreen is deprecated, miPointerGetScreen is all the rage now.

Untested due to lack of device.

2 months agoDriver's don't have to worry about being core pointers anymore.

Peter Hutterer [Thu, 10 Jan 2008 00:55:58 +0000]

Driver's don't have to worry about being core pointers anymore.

The DDX will do the right job, no matter what events we post, so we don't need

in-driver checks for whether to post proximity events or not.

Untested due to a lack of device.

2 months agoPatch with a load of fixes, backported from aiptektablet.sourceforge.net

Rene van Paassen [Thu, 10 Jan 2008 00:53:06 +0000]

Patch with a load of fixes, backported from aiptektablet.sourceforge.net

Tested with re-branded aiptek 12000U

Those entries are from here: http://gitweb.freedesktop.org/?p=xorg/driver/xf86-input-aiptek.git;a=log
From the aiptek-driver mailing list on sourceforge, Rene (the new maintainer) says that these updates fix the wellknown crashes when using aiptek-tablets with pressure-sensitivy.
As I noticed today, an updated package is in the Debian-Sid Repositories, I'm gonna test it out in a few minutes after I installed the newest updates to my Hardy System and a restart.
I'll report back about my experience.

Steveway (steveway1)
description: updated
Revision history for this message
Steve Langasek (vorlon) wrote :

subscribing motu-release, this is a universe package.

Please note that you should also provide the information specified at <https://wiki.ubuntu.com/FreezeExceptionProcess#head-9523bc4076ff011324d67cddc97969ec609618d6>; feature freeze exceptions are not granted without information about the nature of the changes that need the exception.

Changed in xserver-xorg-input-aiptek:
status: New → Incomplete
Steveway (steveway1)
description: updated
Revision history for this message
Steveway (steveway1) wrote :

Well, the Sid-version installed without a problem but there is another one:
The Udev rule to create a Symlink to the aiptekdevice doesn't work.
This is the rule:
# udev rule for aiptek tablets

KERNEL=="event[0-9]*", SYSFS{vendor_id}=="0x08ca", SYMLINK+="input/aiptektablet"

And it's saved as: /etc/udev/rules.d/66-aiptek.rules
But it doesn't seem to work even though it should.
If I try to directly use the /dev/input/event# that the device is located at then it desperatly avoids my decision.
Example:
The device is at /dev/input/event9
I edit my xorg.conf to point to that location.
After a reboot my Synaptic touchpad shows at event9 and my aiptek is at event8.
So I can't assign it automatically per udev at bootup nor can I directly use the event#.
Why doesn't the udev-rule work? Is it a temporary bug in Hardy or has something changed and this should be done on anotherway?

Revision history for this message
Steveway (steveway1) wrote :

Another Update:
Eventually after some reboots the entry in my xorg.conf was directed to the correct event#.
It works but there is one little bug.
I seem to have two cursors in the gimp and other similar applications (gsumi, Inkscape).
One is my normal cursor and the other is a circle (only in gimp, everywhere else it is invisible).
It seems like I control both with my tablet and only the normal cursor with my mouse or touchpad.
Only the circle is drawing in the appropiate application.
The problem here is that the cursors seem to get out of sync so the one is for example somewhere on the bottom right of the screen while the other is in the middle of the screen.
I'm gonna test it with my tablet in relative-mode, too to confirm if that is related.
Despite that bug that is only nagging in those applications like the gimp etc the tablet seems to work perfectly.
Pressure-sensitivity finally works and I didn't experience any crash, unlike before.
I'll dig into that "double-cursor-bug" to see if I find something about it, I think I saw something like this mentioned somewhere before.

Revision history for this message
Steveway (steveway1) wrote :

Huuuuuge Sucess!
A lot of Updates and Reboots later I saw today that there is a device called aiptek in my /dev/input directory.
It is a symlink to my aiptek-tablet!
I'm not sure how the symlink got there, who created it, if it is just a script that I made before and that works now but whatever, it's there and it is working.
The problem with the two cursors is gone and everything seems to work exactly as it should.
I'm so happy that this is now working.
I have nothing against using Sid-packages on my System but I would prefer if that bugfix-release gets into Ubuntu's repositories soon.
Thanks Thanks Thanks

Revision history for this message
Scott Kitterman (kitterman) wrote :

Sounds like this is something that merits investigation. Please provide the information required for a freeze exception as requested before. See: https://wiki.ubuntu.com/FreezeExceptionProcess#head-9523bc4076ff011324d67cddc97969ec609618d6

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Here's the diffstat and diff against 1.1.0:

http://lists.debian.org/debian-x/2008/03/msg00362.html

Revision history for this message
StefanPotyra (sistpoty) wrote :

Timo, since you know x quite well, do you want it in?

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Stefan: yes please, I filed the sync-request (dupe of this bug) :)

Revision history for this message
StefanPotyra (sistpoty) wrote :

Then, yes, ACK #1.

Revision history for this message
Scott Kitterman (kitterman) wrote : Re: [Bug 198599] Re: Fix for buggy aiptek-drivers

It's approved. Someone please set to confirmed.

StefanPotyra (sistpoty)
Changed in xserver-xorg-input-aiptek:
status: Incomplete → Confirmed
Revision history for this message
Steveway (steveway1) wrote :

Done
Thanks guys, I'm so glad. Now Aiptek-users can use their tablets pretty easily on Ubuntu.

Changed in xserver-xorg-input-aiptek:
assignee: nobody → steveway1
Revision history for this message
Daniel Holbach (dholbach) wrote :

Bryce: can you please take a look at it?

Revision history for this message
Bryce Harrington (bryce) wrote :

Daniel, looks acceptable to me. Can the sync be done directly, or do you need me or someone to upload?

Changed in xserver-xorg-input-aiptek:
importance: Undecided → High
milestone: none → ubuntu-8.04
status: Confirmed → In Progress
Revision history for this message
Scott Kitterman (kitterman) wrote :

Looks like someone just needs to make a sync request to me.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

That request has been already done, and marked as a dupe of this bug...

Revision history for this message
Bryce Harrington (bryce) wrote :

Hmm, I don't see any dupes for this bug - what was the bug id? Perhaps is this fixed now?

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

It was bug 200788, and I unduped it and the driver is now synced.

Changed in xserver-xorg-input-aiptek:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.