# Trust TB-7300 not working ( but it should! )

## Dragonlord

Trying to get a TB-7300 to work. This is basically a "Aiptek 14000U" or Genius "M712".

Installed x11-drivers/xf86-input-aiptek ( 1.2.0 ) and compiled xorg with aiptek added to INPUT_DEVICES. Added the aiptek kernel module ( compiled in ). Dmesg shows it loading:

```
usbcore: registered new interface driver aiptek

aiptek: v2.3 (May 2, 2007):Aiptek HyperPen USB Tablet Driver (Linux 2.6.x)

aiptek: Bryan W. Headley/Chris Atenasio/Cedric Brun/Rene van Paassen
```

Now if I plug in the tablet gentoo stubbornly keeps assigning it the generic-hid:

from dmesg:

```
usb 5-1: new full speed USB device using ohci_hcd and address 6

usb 5-1: configuration #1 chosen from 1 choice

input: WALTOP International Corp. Media Tablet as /devices/pci0000:00/0000:00:13.0/usb5/5-1/5-1:1.0/input/input9

generic-usb 0003:172F:0500.0008: input: USB HID v1.10 Mouse [WALTOP International Corp. Media Tablet] on usb-0000:00:13.0-1/input0
```

and in the devices:

```
T:  Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=12  MxCh= 0

D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1     

P:  Vendor=172f ProdID=0500 Rev= 1.14                            

S:  Manufacturer=WALTOP International Corp.                      

S:  Product=Media Tablet                                         

C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA                           

I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid

E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=2ms
```

Any idea how I can get gentoo to load the aiptek module for the tablet instead of the generic hid one? It has to work since people are using this tablet in Linux, just gentoo seems to fuck things up.

----------

## VinzC

Have you solved your problem?

I think I have exactly the same issue.

----------

## Dragonlord

Don't know. Have not rebuild the kernel since quite some time and I patch each one myself to deal with this problem properly (by black-listing the ID from the hid driver).

----------

## VinzC

So far, I've been able to have pressure recognized, i.e. I'm able to click with the tablet and draw, varying pressure controlling thickness and/or transparency in Gimp. I simply have added a 10-input-aiptek config file for Hal. I'll post it when I get my hands back on my laptop.

However the main issue remains, i.e. once I "click" the pointer doesn't move anymore and I must lift the pen up then back. I've got all this working despite the generic driver is used. Don't know if forcing the aiptek kernel driver will fix that.

What results have you got on your side?

----------

## Dragonlord

Forcing the driver by black-listing it from the HID one works well so far. Only thing which doesn't work are the button panels around the drawing area. For some reason the driver does not report key-presses for them as it should. The kernel driver does report them that you can see from the code but the X driver counterpart does not forward these key presses to X which is stupid but nothing I can change.

----------

## VinzC

 *Dragonlord wrote:*   

> Forcing the driver by black-listing it from the HID one works well so far. Only thing which doesn't work are the button panels around the drawing area. For some reason the driver does not report key-presses for them as it should. The kernel driver does report them that you can see from the code but the X driver counterpart does not forward these key presses to X which is stupid but nothing I can change.

 

Thanks for the info. Might sound a stupid question but how do you black list the generic HID driver for that specific hardware? I only know of the global blacklist file in fact.

----------

## Dragonlord

drivers/hid/hid-core.c . Somewhere halfway down the file is this list:

```
/* a list of devices that shouldn't be handled by HID core at all */

static const struct hid_device_id hid_ignore_list[] = {
```

At the end add a line so it looks like this:

```
        { HID_USB_DEVICE(USB_VENDOR_ID_YEALINK, USB_DEVICE_ID_YEALINK_P1K_P4K_B2K) },

        { HID_USB_DEVICE(0x172F, 0x0500) }, // prevent hid core from handling trust tablet

        { }

};
```

I think that's all you have to do. Not sure right now.

----------

## VinzC

Aaaah, ok. Thanks a lot. Going to try that right now.

EDIT: It looks like these changes are being included in the future 2.6.37 kernel. I've browsed quite a lot of source files and I have seen USB_VENDOR_ID_WALTOP was already defined multiple times. So I guess these changes have been committed in the very latest kernel sources. Nikolai Kondrashov has submitted patches for Waltop tablets.

----------

## Dragonlord

Not necessarily. Trust tablets have as far as I know a different ID although they are the same tablet underneath. Check out if the symbol really resolves to 0x172F. If so then all is fine. If not then you still have to patch by hand.

----------

## VinzC

See here  :Smile:  . It's only the first of a series of patches; more recent ones do include ID's for 14.1 inches tablets (i.e. mine  :Smile:  ). So that's good news, I'm sure.

Here's the patch I've "created" from bits of the official ones. It only includes the descriptors and blacklist IDs as I was too lazy collecting and checking everything. I'm almost sure if you install git-sources or even the latest vanilla sources, that patch series will be included.

```
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c

index 7f26ffe..be39a39 100644

--- a/drivers/hid/hid-core.c

+++ b/drivers/hid/hid-core.c

@@ -1389,6 +1389,10 @@ static const struct hid_device_id hid_blacklist[] = {

    { HID_USB_DEVICE(USB_VENDOR_ID_UCLOGIC, USB_DEVICE_ID_UCLOGIC_TABLET_WP8060U) },

    { HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP, USB_DEVICE_ID_SMARTJOY_PLUS) },

    { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_GRAPHIRE_BLUETOOTH) },

+   { HID_USB_DEVICE(USB_VENDOR_ID_WALTOP, USB_DEVICE_ID_WALTOP_SLIM_TABLET_5_8_INCH) },

+   { HID_USB_DEVICE(USB_VENDOR_ID_WALTOP, USB_DEVICE_ID_WALTOP_SLIM_TABLET_12_1_INCH) },

+   { HID_USB_DEVICE(USB_VENDOR_ID_WALTOP, USB_DEVICE_ID_WALTOP_MEDIA_TABLET_10_6_INCH) },

+   { HID_USB_DEVICE(USB_VENDOR_ID_WALTOP, USB_DEVICE_ID_WALTOP_MEDIA_TABLET_14_1_INCH) },

    { HID_USB_DEVICE(USB_VENDOR_ID_ZEROPLUS, 0x0005) },

    { HID_USB_DEVICE(USB_VENDOR_ID_ZEROPLUS, 0x0030) },

    { HID_USB_DEVICE(USB_VENDOR_ID_ZYDACRON, USB_DEVICE_ID_ZYDACRON_REMOTE_CONTROL) },

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h

index b887e73..5be6293 100644

--- a/drivers/hid/hid-ids.h

+++ b/drivers/hid/hid-ids.h

@@ -519,6 +519,12 @@

 #define USB_VENDOR_ID_WACOM      0x056a

 #define USB_DEVICE_ID_WACOM_GRAPHIRE_BLUETOOTH   0x81

 

+#define USB_VENDOR_ID_WALTOP            0x172f

+#define USB_DEVICE_ID_WALTOP_SLIM_TABLET_5_8_INCH   0x0032

+#define USB_DEVICE_ID_WALTOP_SLIM_TABLET_12_1_INCH   0x0034

+#define USB_DEVICE_ID_WALTOP_MEDIA_TABLET_10_6_INCH   0x0501

+#define USB_DEVICE_ID_WALTOP_MEDIA_TABLET_14_1_INCH   0x0500

+

 #define USB_VENDOR_ID_WISEGROUP      0x0925

 #define USB_DEVICE_ID_SMARTJOY_PLUS   0x0005

 #define USB_DEVICE_ID_1_PHIDGETSERVO_20   0x8101
```

----------

## VinzC

Well, done patching and the tablet is now non-functional  :Sad:  . I guess I'll try one of the 2.6.37 kernel candidates around.

----------

## Dragonlord

Looks like the right IDs are there. So the manual patching might have an end now soon. Left is fixing the stupidly broken X driver counterpart *hrmpf*.

----------

## VinzC

May I ask if and what you've put in HAL fdi policy directory to have the tablet be somehow usable in X? Mine is just silent under X but I guess I might have missed something. It works in a TTY with vanilla 2.6.37 though not very useful...

----------

## Dragonlord

Just a little file to set the configuration for X.

```
/etc/hal/fdi/policy/11-aiptek.fdi :

<?xml version="1.0" encoding="UTF-8"?> 

<deviceinfo version="0.2">

  <device>

    <match key="info.product" contains="Aiptek">

      <merge key="info.product" type="string">stylus</merge>

      

      <merge key="input.x11_driver" type="string">aiptek</merge>

      <merge key="input.x11_options.Device" type="string">/dev/input/aiptektablet</merge>

      <merge key="input.x11_options.SendCoreEvents" type="string">true</merge>

      <merge key="input.x11_options.USB" type="string">On</merge>

      <merge key="input.x11_options.Type" type="string">stylus</merge>

      <merge key="input.x11_options.Mode" type="string">absolute</merge>

      

      <merge key="input.x11_options.xTop" type="string">800</merge>

      <merge key="input.x11_options.yTop" type="string">2000</merge>

      <merge key="input.x11_options.xBottom" type="string">46700</merge>

      <merge key="input.x11_options.yBottom" type="string">28600</merge>

      <merge key="input.x11_options.zMin" type="string">0</merge>

      <merge key="input.x11_options.zMax" type="string">1023</merge> <!-- 511 -->

      

      <merge key="input.x11_options.KeepShape" type="string">On</merge>

    </match>

  </device>

</deviceinfo>
```

Pick the device for your case. I just re-routed it to a fixed name as I like clear text device nodes instead of cryptic ones:

```
/etc/udev/rules.d/59-aiptek.rules :

KERNEL=="event[0-9]*", SYSFS{idVendor}=="172f", SYSFS{idProduct}=="0500", SYMLINK+="input/aiptektablet"
```

Not sure though if the udev one is still used. Since a couple of month udev moans about some syntax change but it flashes by during boot process for a fraction of a second so no idea what exactly it is. Boot process logging under Gentoo still suck major balls.

----------

## VinzC

Thanks for the info. What I find strange is the <match> key. Isn't it supposed to contain the same kind of info as what we get with lshal? In my case info.product doesn't contain Aiptek but WALTOP and sometimes [Ww]altop .

----------

## Dragonlord

I don't know. I got this some time ago from an Ubuntu guide. I still hate HAL for being the most clumsy tech product right after win-crap. They should start making

- a "real" GUI editor to manage the configuration

- a discovery tool (gui or commandline) which shows you the important device information and produces a valid FDI from it

- a documentation of all the crap involved with HAL

Using HAL is like trying to cross a river in super thick fog: no way to tell where you are or where the fuck you are going <.=.<

----------

## VinzC

Yeah, I pretty agree with you. Fortunately, X is giving up HAL and going d-bus entirely instead. I know DBUS is no nicer as it carries out the same XML config crap but at least HAL will be out of the way.

----------

## Dragonlord

Never got the hang on D-Bus neither. What exactly is it supposed to be in the end? Right now it looks to me like a bad replacement for IPC.

----------

## VinzC

 *Dragonlord wrote:*   

> Never got the hang on D-Bus neither. What exactly is it supposed to be in the end? Right now it looks to me like a bad replacement for IPC.

 

D-Bus is another IPC system for which there's been an inclusion into the kernel. Don't ask what for I don't remember  :Very Happy:  .

BTW I'm still not able to use my tablet. From the file you gave me I had to remove the line that says

```
<merge key="input.x11_options.Device" type="string">/dev/input/aiptektablet</merge>
```

for I don't have that device node. (I know your UDEV rule file creates it but I was confident an Xorg driver would be smart enough to handle them directly.) In fact it just works in a TTY but not inside X. The pointer remains still whatever. I start to regret buying that sh***t... I should have gone for a Wacom instead but there was just none  :Sad:  . I really have no idea what I'm supposed to do with it.

----------

## Dragonlord

Are you sure you have compiled with INPUT_DEVICES+=aiptek ? Also do not have wacom compiled in as it tends to grab it with some boiler plate code that does not work at all.

----------

## VinzC

 *Dragonlord wrote:*   

> Are you sure you have compiled with INPUT_DEVICES+=aiptek ? Also do not have wacom compiled in as it tends to grab it with some boiler plate code that does not work at all.

 

I do have driver aiptek compiled but I didn't remove the wacom one. I'll make another attempt.

----------

## Dragonlord

It's likely this causes the trouble. Before the aiptek driver existed the wacom one had been befitted with some aiptek code to handle it too. Some guides mention also to do it that way but I found this wacom internal aiptek code to be horribly broken. Watch out to remove wacom from both X and the kernel to avoid conflicts. Since the wacom driver is older it takes precedence in every case.

----------

## VinzC

Thanks for your lights. The twist is I have a Wacom tablet, which is quite functional. So I will probably use an intermediate kernel with multiboot for my tests.

----------

## Dragonlord

Maybe you can blacklist the wacom driver from taking control of certain device nodes. HAL should be able to do this I think but I'm not too proficient with that piece of sh... software <.=.<

----------

## VinzC

 :Laughing: 

Thanks again for the tip  :Smile:  .

----------

## VinzC

Yeeeeehaaaaaaaaaaaaaaa! It was a pain-in-the-ass but it was worthwhile!

I have at last succeeded in making my Trust tablet work. It's a tough work but it's really worth the pain. Here's what I had to do.

I disabled HAL (required for Xorg 1. :Cool:  so I removed hal from *all* my USE flags (don't do it halfway  :Very Happy: )

Upgraded Xfce to version 4.7 (because of better support for udev and other issues with Seahorse, SSH agent)

upgraded Xorg to version 1.8

created a set of input files for keyboard (belgian), touchpad (synaptics) and tablets.

Period. Well, almost because it took me quite a few compiles and revdep-rebuild to get that thing to work but I was really late for upgrading Gentoo. It was one massive upgrade again but now it works.

```
Section "InputClass"

        Identifier "Wacom class"

# WALTOP needs a patched kernel driver, that isn't in mainline lk yet,

# so for now just let it fall through and be picked up by evdev instead.

        MatchProduct "Wacom|WALTOP|WACOM"

        MatchDevicePath "/dev/input/event*"

        Driver "wacom"

EndSection
```

```
Section "InputClass"

        Identifier      "Keyboard0"

        Driver          "evdev"

        Option          "xkbModel"      "Dell"

        Option          "xkbLayout"     "be"

        MatchIsKeyboard "on"

EndSection
```

```
Section "InputClass"

        Identifier      "Touchpad0"

        Driver          "synaptics"

        Option          "VertEdgeScroll" "true"

        Option          "HorizEdgeScroll" "true"

        MatchIsTouchpad "on"

EndSection
```

As far as the tablet is concerned, I get pressure sensitivity in Gimp. Media buttons aren't working yet (especially the wheels) but it's a good start. Current kernel: 2.6.36-gentoo-r1. Maybe switching to 2.6.37 will take care of the few IOCTL error messages I have in Xorg log file. But I'm more than happy for the time being. I had to share that.

```
[  6440.713] (EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device

[  6440.729] (EE) PreInit returned NULL for "WALTOP International Corp. Media Tablet"

[  6441.526] (EE) SynPS/2 Synaptics TouchPad Unable to query/initialize Synaptics hardware.

[  6441.542] (EE) PreInit failed for input device "SynPS/2 Synaptics TouchPad"
```

Hope this helps.

----------

