evdev and Trust TB-5300 tablet: wrong axis labels

[Matthew Helsley]

On Mon, Dec 14, 2009 at 3:46 PM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> On Tue, Dec 15, 2009 at 01:06:07AM +0200, Daniil V. Kolpakov wrote:
>> В сообщении от 14 декабря 2009 Matthew Helsley написал(a):
>> [...]
>> > Looks like they may have re-branded the "Genius MousePen 5x4 Tablet"
>> > to your "Trust TB-5300".
>> [...]
>> > If you search for "Genius MousePen 5x4 Tablet" or something like it
>> > then perhaps you'll find more ideas for fixing your tablet.
>>
>> Nothing interesting -- mostly I get howtos on installing some (proprietary?)
>> driver called "wizardpen", and usually with xorg.conf instead of HAL rules.
>>
>> I've tried enabling "MULTI_INPUT" quirk, as you've suggested:
>>
>> [root at shinestar:~]$ modprobe -r usbhid
>> [root at shinestar:~]$ modprobe usbhid "quirks=0x5543:0x0004:0x0040"
>>
>> It "splitted" the tablet to three devices, as in your case:
>>
>> I: Bus=0003 Vendor=5543 Product=0004 Version=0100
>> N: Name="UC-LOGIC Tablet WP5540U"
>> P: Phys=usb-0000:03:00.0-2/input0
>> S:
>> Sysfs=/devices/pci0000:00/0000:00:06.0/0000:03:00.0/usb1/1-2/1-2:1.0/input/input15
>> U: Uniq=
>> H: Handlers=mouse2 event6
>> B: EV=1b
>> B: KEY=c01 1 0 0 0 0
>> B: ABS=1000003
>> B: MSC=10
>>
>> I: Bus=0003 Vendor=5543 Product=0004 Version=0100
>> N: Name="UC-LOGIC Tablet WP5540U"
>> P: Phys=usb-0000:03:00.0-2/input0
>> S:
>> Sysfs=/devices/pci0000:00/0000:00:06.0/0000:03:00.0/usb1/1-2/1-2:1.0/input/input16
>> U: Uniq=
>> H: Handlers=mouse3 event7
>> B: EV=17
>> B: KEY=70000 0 0 0 0
>> B: REL=303
>> B: MSC=10
>>
>> I: Bus=0003 Vendor=5543 Product=0004 Version=0100
>> N: Name="UC-LOGIC Tablet WP5540U"
>> P: Phys=usb-0000:03:00.0-2/input0
>> S:
>> Sysfs=/devices/pci0000:00/0000:00:06.0/0000:03:00.0/usb1/1-2/1-2:1.0/input/input17
>> U: Uniq=
>> H: Handlers=mouse4 event8
>> B: EV=1b
>> B: KEY=400 70000 0 0 0 0
>> B: ABS=1000003
>> B: MSC=10
>>
>> But xinput only gets two of them. They don't send events (xinput test shows
>> this). But, looking at Xorg.0.log now, I see that the first device is hooked
>> by synaptics driver which cannot init because hardware is unsupported. I know
>> why, I've seen overriding rules in hal config. I'll try to reconfigure it to
>> use evdev driver.
>
> synaptics kicks in after the catchall evdev configuration and overwrites it.
> the reason why it overrides for this device is that anything with absolute
> x/y coordinates and buttons are labelled as touchpads by HAL and the default
> configurations then hook onto this label.
>
> easiest workaround is to drop in your custom configuration into
> /etc/hal/fdi/policies/ and (if you already have another one there) make sure
> that it's loaded last.  HAL uses alphasort when reading the directories.
>
> the match rule needed is something like this:
>
> <match key="input.product" contains="U-LOGIC">

Mine reports "UC-Logic Technology Corp." as the usb.vendor string. My
"input.product" for that device is exactly "    Tablet PF1209" (space
included). So the rule would have to check the usb.vendor_id of the
parent "node".

For my tablet I chose to be quite specific:

<match key="info.capabilities" contains="input.touchpad">
<match key="info.product" contains="Tablet PF1209">
<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"
string="Linux">

(I chose the last since evdev is a Linux driver and I didn't know
whether my changes to these .fdi files might eventually be useful on a
*BSD.)

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

Yes, I've hit this problem and I keep forgetting about it because it's
hidden in the .fdi files, waiting for whenever my distro "upgrades"
them. Sorry, Daniil, I completely forgot to mention this problem :(.

<tangent>
The .fdi file that assigns the synaptic driver to these devices based
solely on the "input.touchpad" capability seems quite wrong to me. My
guess is most tablets that rely on evdev will report absolute
coordinates. If anything, based on their comparably-small physical
size, I'd expect "touchpads" would report relative coordinates. Plus
synaptic can't be the only touchpad vendor/whatnot, can it? Why should
its driver try to claim them all?

Perhaps it should have it's own match key:

<match key="info.product" contains="Synaptics TouchPad">

(which works for my touchpad at least) rather than:

<match key="info.capabilities" contains="input.touchpad">

Sorry, I don't know: Who maintains the .fdi files -- the driver
developer, the distro, or HAL developers? In my distro they're in
/usr/share/hal/policy and the way its packaged suggests the driver
developers are responsible.

Peter am I way off here?
</tangent>

Cheers,
    -Matt Helsley