Re: evdev and Trust TB-5300 tablet: wrong axis labels
On Mon, Dec 14, 2009 at 3:46 PM, Peter Hutterer 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: >> >> [r...@shinestar:~]$ modprobe -r usbhid >> [r...@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-:03:00.0-2/input0 >> S: >> Sysfs=/devices/pci:00/:00:06.0/: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=103 >> B: MSC=10 >> >> I: Bus=0003 Vendor=5543 Product=0004 Version=0100 >> N: Name="UC-LOGIC Tablet WP5540U" >> P: Phys=usb-:03:00.0-2/input0 >> S: >> Sysfs=/devices/pci:00/:00:06.0/:03:00.0/usb1/1-2/1-2:1.0/input/input16 >> U: Uniq= >> H: Handlers=mouse3 event7 >> B: EV=17 >> B: KEY=7 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-:03:00.0-2/input0 >> S: >> Sysfs=/devices/pci:00/:00:06.0/:03:00.0/usb1/1-2/1-2:1.0/input/input17 >> U: Uniq= >> H: Handlers=mouse4 event8 >> B: EV=1b >> B: KEY=400 7 0 0 0 0 >> B: ABS=103 >> 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: > > 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: (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.) > evdev > 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 :(. 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: (which works for my touchpad at least) rather than: 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? Cheers, -Matt Helsley ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: evdev and Trust TB-5300 tablet: wrong axis labels
2009/12/13 Daniil V. Kolpakov : > Matthew, thanks for the info! You're quite welcome! > В сообщении от 13 декабря 2009 Matthew Helsley написал(a): >> What does /proc/bus/input/devices say about your tablet? I've got a >> UC-LOGIC "Genius Pensketch 12x9" which had (and still has) some USB >> quirks. The worst was it reported the X axis as the Z axis. It turned >> out that the hid descriptor was bad and thus the kernel hid parser got >> confused. Specifying the "MULTI" quirk seemed to fix the axis >> labelling problem. You can test it and other quirks out by writing to >> a sysfs file -- though I'm looking and can't seem to find it on my >> 2.6.31 distro kernel :(. > > /proc/bus/input/devices says pretty much the same as it does in your case: > > I: Bus=0003 Vendor=5543 Product=0004 Version=0100 > N: Name="UC-LOGIC Tablet WP5540U" Looks like they may have re-branded the "Genius MousePen 5x4 Tablet" to your "Trust TB-5300". Here's the usb.ids section which suggests that: 5543 UC-Logic Technology Corp. 0002 SuperPen WP3325U Tablet 0003 Genius MousePen 4x3 Tablet/Aquila L1 Tablet 0004 Genius MousePen 5x4 Tablet 0005 Genius MousePen 8x6 Tablet 0041 Genius PenSketch 6x8 Tablet 0042 Genius PenSketch 12x9 Tablet If you search for "Genius MousePen 5x4 Tablet" or something like it then perhaps you'll find more ideas for fixing your tablet. Of course this could be misleading -- I believe there are examples of vendors re-using USB vendor:product pairs for different products. > P: Phys=usb-:03:00.0-2/input0 > S: > Sysfs=/devices/pci:00/:00:06.0/:03:00.0/usb1/1-2/1-2:1.0/input/input6 > U: Uniq= > H: Handlers=mouse2 event6 To decode the following you can use /usr/include/linux/input.h (assuming you have a libc devel package installed. I've decoded it below: > B: EV=1f > B: KEY=c01 3f0001 0 0 0 0 > B: REL=303 This is: 00110011 which says it reports REL_MISC, REL_WHEEL, REL_Y, and REL_X events. > B: ABS=10f This one says it reports ABS_X, ABS_Y, ABS_Z, ABS_RX and ABS_PRESSURE. So, as you can see, the evdev driver properly decoded what the kernel told it about the device. It seems like the events produced by the kernel are wrong because the hid descriptor is probably broken. Incidentally, you can get a copy of that too. This isn't what I used -- it looks even more helpful: http://old.nabble.com/How-to-dump-HID-report-descriptor-under-Linux-td19609562.html With the example, decoded HID descriptor printed here: http://old.nabble.com/Re%3A-How-to-dump-HID-report-descriptor-under-Linux-p20159409.html Which suggests (running as root user): u...@localhost: ~/$ less /proc/bus/input/devices ... I: Bus=0003 Vendor=5543 Product=0042 Version=0100 ^ N: Name="Tablet PF1209" P: Phys=usb-:00:1d.1-2/input0 S: Sysfs=/devices/pci:00/:00:1d.1/usb6/6-2/6-2:1.0/input/input10 ^^^ ... r...@localhost: ~/# echo '6-2:1.0' > /sys/bus/usb/drivers/usbhid/unbind r...@localhost: ~/# lsusb -vvv -d '5543:0042' Bus 006 Device 002: ID 5543:0042 UC-Logic Technology Corp. Genius PenSketch 12x9 Tablet Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x5543 UC-Logic Technology Corp. idProduct 0x0042 Genius PenSketch 12x9 Tablet bcdDevice0.00 iManufacturer 1 iProduct2 Tablet PF1209 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 34 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 2 Mouse iInterface 2 Tablet PF1209 ** UNRECOGNIZED: 09 21 00 01 00 01 22 ea 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSiz
Re: evdev and Trust TB-5300 tablet: wrong axis labels
2009/12/12 Daniil Kolpakov : > (Sorry, the email was send from wrong address. Resending it.) > > Hi, > > I'm playing with Trust TB-5300 tablet, which gets identified as "UC-LOGIC > Tablet WP5540U" by HAL and xorg loads evdev driver for it on plug. > > I'm getting the following list of axes with xinput list --long: > Abs X, Abs Y, Abs Z, Abs Rotary X, Abs Pressure (5 axes). xinput test shows > output like this: > > motion a[0]=0 a[1]=0 a[2]=32045 a[3]=16538 a[4]=55 > motion a[0]=0 a[1]=0 a[2]=32072 a[3]=16575 a[4]=54 > motion a[0]=0 a[1]=0 a[2]=32114 a[3]=16596 a[4]=49 > > a[0] and a[1] is always 0, a[2] is X, a[3] is Y and a[4] is pressure. What does /proc/bus/input/devices say about your tablet? I've got a UC-LOGIC "Genius Pensketch 12x9" which had (and still has) some USB quirks. The worst was it reported the X axis as the Z axis. It turned out that the hid descriptor was bad and thus the kernel hid parser got confused. Specifying the "MULTI" quirk seemed to fix the axis labelling problem. You can test it and other quirks out by writing to a sysfs file -- though I'm looking and can't seem to find it on my 2.6.31 distro kernel :(. (Cc'ing linux-input and linux-usb in case they can offer help with any potential kernel-level workarounds/fixes/etc) The rest of this email is my own experience with a UC-LOGIC tablet and may or may not be useful to you. Cheers, -Matt Helsley For example, here's my tablet's description in /proc/bus/input/devices before (circa 2.6.24) and after applying the quirk (circa 2.6.31) respectively: BEFORE (1 entry): I: Bus=0003 Vendor=5543 Product=0042 Version=0100 N: Name="Tablet PF1209" P: Phys=usb-:00:02.0-8/input0 S: Sysfs=/devices/pci:00/:00:02.0/usb1/1-8/1-8:1.0/input/input9 U: Uniq= H: Handlers=mouse1 event1 B: EV=1f B: KEY=c01 3f0001 0 0 0 0 B: REL=303 B: ABS=10f B: MSC=10 AFTER (3 entries): I: Bus=0003 Vendor=5543 Product=0042 Version=0100 N: Name="Tablet PF1209" P: Phys=usb-:00:1d.1-2/input0 S: Sysfs=/devices/pci:00/:00:1d.1/usb6/6-2/6-2:1.0/input/input6 U: Uniq= H: Handlers=mouse2 event6 evbug B: EV=1b B: KEY=c01 1 0 0 0 0 B: ABS=103 B: MSC=10 I: Bus=0003 Vendor=5543 Product=0042 Version=0100 N: Name="Tablet PF1209" P: Phys=usb-:00:1d.1-2/input0 S: Sysfs=/devices/pci:00/:00:1d.1/usb6/6-2/6-2:1.0/input/input7 U: Uniq= H: Handlers=mouse3 event7 evbug B: EV=17 B: KEY=7 0 0 0 0 B: REL=303 B: MSC=10 I: Bus=0003 Vendor=5543 Product=0042 Version=0100 N: Name="Tablet PF1209" P: Phys=usb-:00:1d.1-2/input0 S: Sysfs=/devices/pci:00/:00:1d.1/usb6/6-2/6-2:1.0/input/input8 U: Uniq= H: Handlers=mouse4 event8 evbug B: EV=1b B: KEY=400 7 0 0 0 0 B: ABS=103 B: MSC=10 Note how REL and ABS reports don't appear in the same entry anymore. In the original entry, if you decode the bits, you can see that it was claiming to report both relative and absolute axis. Of course this is not, strictly speaking, an indicator of a bug either. However the fact is the "puck" reports relative events while the pen reports absolute events. I could determine this by running a test program on the /dev/input/eventX device mentioned and seeing what kinds of events each triggered. Now with the "MULTI" quirk it produces 3 entries. Some other fun quirks you may look forward too: Unfortunately, only two of the event devices actually emit events. The resolutions and ranges of the axii aren't properly reported on every device. Also the device occaisionally enters a state where all but a thin border of the active area is disabled. "Fixing" this requires hooking the tablet up to a windows box with a usb switch and then "switching" it to the Linux box without powering off. So it seems there are some magic commands the windows driver knows about which I couldn't see in the HID descriptor table (would they be there?) which re-enable/specify the active area. Since getting into the state never happens with the computer/tablet powered on I can't debug this problem. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XI2 pull warning
On Sat, May 30, 2009 at 9:29 AM, John Tapsell wrote: > 2009/5/29 Peter Hutterer : >> On Thu, May 28, 2009 at 02:54:22PM -0400, Thomas Jaeger wrote: >>> Thanks for the work you've put into this. I haven't spent a lot of time >>> testing the new code, but here are my first impressions. You're >>> probably aware of most of the issues below already, but I'll mention >>> them just in case. > > Has anyone from wine had a look at the patch? Might it be good to get > someone from there to sign off on this, since they need the XI2 stuff > to have fairly specific behaviour? > > John Back in April Wine Weekly News mentioned Paul Hampson is working with XInput2: http://www.winehq.org/wwn/357#XInput 2 Spec http://www.winehq.org/pipermail/wine-devel/2009-April/074957.html Cheers, -Matt Helsley ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Adding support for a (multi-)touchscreen - where best to add it?
On Sun, Mar 15, 2009 at 6:05 PM, Peter Hutterer wrote: > On Fri, Mar 13, 2009 at 06:21:04AM -0500, David Hagood wrote: >> On Fri, 2009-03-13 at 11:43 +1000, Peter Hutterer wrote: >> > On Thu, Mar 12, 2009 at 01:40:29PM -0400, Chris Ball wrote: >> >> > I agree. getting something sensible in the kernel prevents us from >> > replicating >> > the "one X driver per device" hilarity. >> > Once we have that support in the kernel, we can look at how to get it to >> > applications in a sensible manner. Real multi-touch is hard, and there are >> > a >> > few roadblocks that I'm not looking forward to. >> > >> > Cheers, >> > Peter >> >> OK, let me break it down into steps: >> >> Step 1: add the code to the kernel HID system to >> 1a) identify this device as being a special case within the HID system >> 1b) send the device the needed special packet to tell it to start >> sending data (otherwise it does nothing). >> 1c) Parse the incoming data (it uses a specific format) into HID >> events. >> >> Alternatively 1a-1c could be done in a userspace library e.g. tslib. >> >> Step 2: Add support at the X input layer to handle those packets, in one >> of the several candidate drivers (e.g. input-tslib, input-evtouch, >> input-evdev). >> As I understand it the consensus here is that this should be in evdev. >> NOTE: currently the other touchscreens I have from 3M and Dannotech do >> NOT work under evdev - when evdev is bound to them it doesn't generate >> any events to X. They do work under tslib and evtouch. > > that's probably because they advertise a button/axis combination that evdev > does interpret correctly, or because they're posting the axis information > wrongly. I had my hands on an HP Touchsmart for a short while and it was > posting x/y through Z/Rx. My Genius PenSketch tablet used to do the same thing. It turned out to be a quirky HID descriptor which was fixed with the MULTI quirk. Once I added that quirk it produced correct HID reports. You can try the quirk with some simple sysfs manipulations or by writing a kernel patch. I went the patch route and only noticed the sysfs method while reading the code -- so I don't know the sysfs details. Other quirks may apply. Cheers, -Matt Helsley ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
