Re: Touchscreen troubles
Tias t...@ulyssis.org [2009-12-12 23:36:07]:
Hi Petr,
Hi Tias,
If you think it is related to calibration, you can try
xinput_calibrator. Its a generic touchscreen calibration utility (still
depends on GTK-mm for now, will be fixed in the next version):
http://www.freedesktop.org/wiki/Software/xinput_calibrator
Thanks, I've modified it little bit to get it working, pls see attached
patches:
custom-device.patch: Allows you to specify which device use want calibrate,
it's necessary if you've more devices. In current state it tries to configure
last device found and in my case it wasn't touchscreen device.
new-values-evdev.patch: In current state it prints out xorg.conf settings for
evtouch driver, so I modified it and now it prints correct values for evdev
driver also, plus commandline values for xinput set-int-prop.
It calibrates the Xorg driver (and the values that the X server
receives). You report calibrating from the values of the kernel, maybe
using a user-space tool will solve your problem ?
I tried values from xinput_calibrator after calibration, but the situation is
same as it was before, I still can't access bottom-right part of screen and
it's even worse with this values, because now the touches in top-left area are
bit off few points, pointer movement doesn't match touches.
What do you mean by user-space tool?
If you want to find out what the X server thinks of your touchscreen
actions, install xinput and run:
xinput test TS name
you can also check the output of
xinput query-state TS name
to find out the exact coordinates of your touches.
(this will probably be similar to the 'xidump' you mentioned though)
Yes, I tried that also before, but it's same, seems like correct values which
match kernel values. I'll try to dig into Xserver code to find out what's
going on. My 22 touchscreen is 16:10, shouldn't that be a problem?
Thanks a lot for your suggestions.
-- ynezz
Index: xinput_calibrator/xinput_calibrator.cc
===
--- xinput_calibrator.orig/xinput_calibrator.cc 2009-12-13 13:09:03.0 +0100
+++ xinput_calibrator/xinput_calibrator.cc 2009-12-13 13:40:38.0 +0100
@@ -281,7 +281,7 @@
/* We ignore flip_x and flip_y,
* the min/max values will already be flipped and drivers can handle this */
- printf (Suggested new values for xorg.conf:\n);
+ printf (Suggested new values for xorg.conf, evtouch driver:\n);
printf (\tOption\t\MinX\\t\t\%d\\t# was \%d\\n,
min_x, oldcalib_min_x);
printf (\tOption\t\MaxX\\t\t\%d\\t# was \%d\\n,
@@ -291,6 +291,15 @@
printf (\tOption\t\MaxY\\t\t\%d\\t# was \%d\\n,
max_y, oldcalib_max_y);
printf (\tOption\t\SwapXY\\t\%d\\n, swap_xy);
+ printf (\nSuggested new values for xorg.conf, evdev driver:\n);
+ printf (\tOption\t\Calibration\\t\%d %d %d %d\\t# was \%d %d %d %d\\n,
+min_x, max_x, min_y, max_y, oldcalib_min_x, oldcalib_max_x,
+oldcalib_min_y, oldcalib_max_y);
+ printf (\tOption\t\SwapXY\\t\%d\\n, swap_xy);
+ printf (\nOr you can set it online running this commands:\n);
+ printf (\txinput set-int-prop %s \Evdev Axis Calibration\ 32
+ %d %d %d %d\n, drivername, min_x, max_x, min_y, max_y);
+ printf (\txinput set-int-prop %s \Evdev Axes Swap\ 8 %d\n, drivername, swap_xy);
}
Index: xinput_calibrator/xinput_calibrator.cc
===
--- xinput_calibrator.orig/xinput_calibrator.cc 2009-12-13 13:09:35.0 +0100
+++ xinput_calibrator/xinput_calibrator.cc 2009-12-13 13:10:53.0 +0100
@@ -23,8 +23,9 @@
* Authors:
* Soren Hauberg (haub...@gmail.com)
* Tias Guns (t...@ulyssis.org)
+ * Petr Stetiar (ynez...@true.cz)
*
- * Version: 0.2.0
+ * Version: 0.2.1
*
* Make: g++ -Wall xinput_calibrator.cc `pkg-config --cflags --libs gtkmm-2.4` -o xinput_calibrator
*/
Index: xinput_calibrator/xinput_calibrator.cc
===
--- xinput_calibrator.orig/xinput_calibrator.cc 2009-12-13 11:47:15.0 +0100
+++ xinput_calibrator/xinput_calibrator.cc 2009-12-13 13:09:03.0 +0100
@@ -476,6 +476,8 @@
{
public:
CalibrationArea ();
+ void init ();
+ void set_device (const char *name) { device_name = name; };
protected:
/* Helper functions */
@@ -491,10 +493,15 @@
int num_clicks, width, height;
Calibrator* W;
int time_elapsed;
+ const char *device_name;
};
CalibrationArea::CalibrationArea ()
- : num_clicks (0), time_elapsed (0)
+ : num_clicks (0), time_elapsed (0), device_name (0)
+{
+}
+
+void CalibrationArea::init ()
{
/* Not sure this is the right place for this, but here we go
* Get driver name and axis information from XInput */
@@ -540,6 +547,12 @@
max_x = ax[0].max_value;
min_y = ax[1].min_value;
max_y = ax[1].max_value;
+
+
Re: Touchscreen troubles
Hey Petr, Petr Štetiar wrote: Tias t...@ulyssis.org [2009-12-12 23:36:07]: Hi Petr, Hi Tias, If you think it is related to calibration, you can try xinput_calibrator. Its a generic touchscreen calibration utility (still depends on GTK-mm for now, will be fixed in the next version): http://www.freedesktop.org/wiki/Software/xinput_calibrator Thanks, I've modified it little bit to get it working, pls see attached patches: custom-device.patch: Allows you to specify which device use want calibrate, it's necessary if you've more devices. In current state it tries to configure last device found and in my case it wasn't touchscreen device. new-values-evdev.patch: In current state it prints out xorg.conf settings for evtouch driver, so I modified it and now it prints correct values for evdev driver also, plus commandline values for xinput set-int-prop. Thanks for the patches. Normally the calibrator checks if you have an EvDev driver (in CalibratorEvdev::check_driver) and already prints those things. It's kind of strange that it did not detect you were using evdev. It checks for the same properties as the command line xinput set-int-prop settings, so I don't understand what goes wrong ? It calibrates the Xorg driver (and the values that the X server receives). You report calibrating from the values of the kernel, maybe using a user-space tool will solve your problem ? I tried values from xinput_calibrator after calibration, but the situation is same as it was before, I still can't access bottom-right part of screen and it's even worse with this values, because now the touches in top-left area are bit off few points, pointer movement doesn't match touches. Make sure you set xinput set-int-prop ... Evdev Axis Calibration 32 0 before calibrating (as it does not correctly detect your current calibration values). Although that it really does seem to be a deeper issue then a wrong calibration... What do you mean by user-space tool? Not calibrating the kernel values (by doing printk), but calibrating the Xorg driver (as you are currently doing). If you want to find out what the X server thinks of your touchscreen actions, install xinput and run: xinput test TS name you can also check the output of xinput query-state TS name to find out the exact coordinates of your touches. (this will probably be similar to the 'xidump' you mentioned though) Yes, I tried that also before, but it's same, seems like correct values which match kernel values. I'll try to dig into Xserver code to find out what's going on. My 22 touchscreen is 16:10, shouldn't that be a problem? I have no idea if there are any limits on screen size or ratio... Looking at your original email, I see you are using Xorg server 1.6.0 with evdev 2.3.2 manually compiled. It might just be a version thing of course. I would definitely try it on a recent system with a standard setup too. g,T Thanks a lot for your suggestions. -- ynezz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Touchscreen troubles
Tias t...@ulyssis.org [2009-12-13 18:05:23]: Thanks for the patches. Normally the calibrator checks if you have an EvDev driver (in CalibratorEvdev::check_driver) and already prints those things. It's kind of strange that it did not detect you were using evdev. It checks for the same properties as the command line xinput set-int-prop settings, so I don't understand what goes wrong ? Ok, I'll check this. It calibrates the Xorg driver (and the values that the X server receives). You report calibrating from the values of the kernel, maybe using a user-space tool will solve your problem ? Yes, but I just use this kernel values to get min/max values for both axes. For nothing else. And I got similar values from evtouch_calibrate, BTW. Make sure you set xinput set-int-prop ... Evdev Axis Calibration 32 0 before calibrating (as it does not correctly detect your current calibration values). You mean ... Evdev Axis Calibration 32 0 0 0 0 - four zeros, with one zero I got error from xinput. Althought I do this, I can now press only top-left circle, then the mouse pointer moves to 0,0 coordinates on the screen, and I'm unable to touch another circle in top-right corner, and in Xorg log i see: Divide by Zero in xf86ScaleAxisDivide by Zero in xf86ScaleAxis(II) and I see my debug msg touchscreen: num_valuators: 2 x: 0 y: 0, means both valuators are 0. What do you mean by user-space tool? Not calibrating the kernel values (by doing printk), but calibrating the Xorg driver (as you are currently doing). Ah, you maybe misunderstood me here, I used those values which kernel driver outputs when usermode read()s from /dev/input/device to get just min/max axis values and I use it for Xorg calibration, it's not possible to calibrate this kind of touchscreen anyway. Looking at your original email, I see you are using Xorg server 1.6.0 with evdev 2.3.2 manually compiled. It might just be a version thing of course. I would definitely try it on a recent system with a standard setup too. It was the same with standard setup, so that's why I'm trying first with lates evdev driver... -- ynezz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: evdev and Trust TB-5300 tablet: wrong axis labels
В сообщении от 13 декабря 2009 Daniil V. Kolpakov написал(a): I can't find any information on how to enable quirks through sysfs (and where to get list of available quirks, too). Can you point me to some documentation on this subject? Hmm, it must be /sys/module/usbhid/parameters/quirks file! But what's the format, and how do I know the values for enabling MULTI quirk? -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Support open standards! Take a look at this nice presentation: http://www.dwheeler.com/essays/open-standards-security.pdf ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: evdev and Trust TB-5300 tablet: wrong axis labels
В сообщении от 13 декабря 2009 Daniil V. Kolpakov написал(a): В сообщении от 13 декабря 2009 Daniil V. Kolpakov написал(a): I can't find any information on how to enable quirks through sysfs (and where to get list of available quirks, too). Can you point me to some documentation on this subject? Hmm, it must be /sys/module/usbhid/parameters/quirks file! But what's the format, and how do I know the values for enabling MULTI quirk? $ /sbin/modinfo usbhid | grep quirks parm: quirks:Add/modify USB HID quirks by specifying quirks=vendorID:productID:quirks where vendorID, productID, and quirks are all in 0x-prefixed hex (array of charp) I guess reading usbhid source should drop some light on my question :) -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Support open standards! Take a look at this nice presentation: http://www.dwheeler.com/essays/open-standards-security.pdf ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Touchscreen troubles
Petr Štetiar yn...@true.cz [2009-12-11 22:41:18]:
Hi,
I'm trying to get working 22 resistive 5-wire touchscreen with USB
controller, it's ETT TC5UH[1]. I'm using Ubuntu 9.04 with Xorg server 1.6.0,
evdev version 2.3.2 compiled manualy. I've set calibration[1] gathered using
values from kernel printk. It kind of works, but only on half of the screen,
top-lef part:
crappy-ascii-art
[x=284; y=279] [x=1846; y=230] [x=3633; y=189]
+-+---+
|. / |
| . / |
| working part . / |
| . / |
[x=209; y=1914] + . + [x=1352; y=1697] + [x=2697; y=1212]
| . / |
| . / not working |
| . / part |
| / |
+-+---+
[x=165; y=3652] [x=875; y=3023][x=1693; y=2136]
/crappy-ascii-art
If I touch bottom-right corner I get from kernel driver x=1685, y=2220 and
from xidump x=1785, y=2383 and it seems like almost correct values, but cursor
is moving only in top-left part, near middle of the screen. I tried without
calibration values also, swapping axes, but I can't get it working. For me, it
seems, that the kernel reported and evdev reported values are correct, but
it's then wrongly interpreted somewhere in Xorg code, and pointer doesn't move
correctly.
Ok, I've added verbose debug code into xserver and here is what I've observed
so far(sorry, it's not linewrapped, but it should be more readable):
[start of log]
--
Touchscreen calibrated with:
--
Evdev Axis Calibration (225): 66, 2933, 45, 3257
Touch in top-right corner:
--
kernel:
~~~
[100077.271713] tc5uh x: 3639 y: 198 touch: 1)
xserver:
(II) evdev: touchscreen: num_valuators: 2 x: 4095 y: 181
(II) [!] XINPUT: called with x: 4095 y: 181 num: 2.
(II) [!] XINPUT: pointer is absolute.
(II) [!] XINPUT: have XFreeXDGA.
(II) [!] XINPUT: if (num_valuators = 1 first_valuator = 1) {
(II) [!] XINPUT: if (first_valuator == 0) dx is now: 4095
(II) [!] XINPUT: if (is_absolute) { dx is now: 2 last.valuators[0]=4093
(II) [!] XINPUT: if (first_valuator == 1 || num_valuators = 2) dy is
now: 181
(II) [!] XINPUT: if (is_absolute) { dy is now: -7 last.valuators[1]=188
(II) [!] XINPUT: before if (DGAStealMotionEvent(device, index=0, dx=2,
dy=-7)) { return; }
(II) [!] DGA: DGAStealMotionEvent called with index=0, dx=2, dy=-7));
(II) [!] DGA: no direct mode.
(II) [!] XINPUT: GetPointerEvents() x: 4095 y 181 num: 2.
[!] DIX: GetPointerEvents() called with num_valuators: 2 x: 4095 y: 181
[!] DIX: GetPointerEvents() continues...
[!] DIX: GetPointerEvents() calling moveAbsolute with num_valuators: 2
x: 4095 y: 181 screen: 1680x1050
[1] [!] DIX: GetPointerEvents() before getValuatorEvents num_valuators: 2
x: 4093 y: 181 root_x: 1679 root_y: 46
Touch in bottom-right corner:
-
kernel:
~~~
[99979.098016] tc5uh x: 1686 y: 2233 touch: 0)
xserver:
(II) evdev: touchscreen: num_valuators: 2 x: 2311 y: 2794
(II) [!] XINPUT: called with x: 2311 y: 2794 num: 2.
(II) [!] XINPUT: pointer is absolute.
(II) [!] XINPUT: if (num_valuators = 1 first_valuator = 1) {
(II) [!] XINPUT: if (first_valuator == 0) dx is now: 2311
(II) [!] XINPUT: if (is_absolute) { dx is now: -1782
last.valuators[0]=4093
(II) [!] XINPUT: if (first_valuator == 1 || num_valuators = 2) dy is
now: 2794
(II) [!] XINPUT: if (is_absolute) { dy is now: 2613
last.valuators[1]=181
(II) [!] XINPUT: before if (DGAStealMotionEvent(device, index=0,
dx=-1782, dy=2613)) { return; }
(II) [!] DGA: DGAStealMotionEvent called with index=0, dx=-1782,
dy=2613));
(II) [!] DGA: no direct mode.
(II) [!] XINPUT: GetPointerEvents() x: 2311 y 2794 num: 2.
[!] DIX: GetPointerEvents() called with num_valuators: 2 x: 2311 y: 2794
[!] DIX: GetPointerEvents() continues...
[!] DIX: GetPointerEvents() calling moveAbsolute with num_valuators: 2
x: 2311 y: 2794 screen: 1680x1050
[2] [!] DIX: GetPointerEvents() before getValuatorEvents num_valuators: 2
x: 2311 y: 2794 root_x: 948 root_y: 716
[end of log]
--
Comments:
~
1.
Re: Is HandleSpecialKeys expected to work when xkeyboard is disabled?
On Sat, Dec 12, 2009 at 01:54:12PM -0800, Derek Fawcus wrote: On Sun, Dec 13, 2009 at 07:19:40AM +1000, Peter Hutterer wrote: out of interest, which documentation refers to the handling of special keys working without XKB? man Xorg KEYBOARD The Xorg server is normally configured to recognize various special combinations of key presses that instruct the server to perform some action, rather than just sending the key press event to a client application. The default XKEYBOARD keymap defines the key combina- tions listed below. The server also has these key combinations builtin to its event handler for cases where the XKEYBOARD extension is not being used. Last sentance above. man xorg.conf Option HandleSpecialKeys when This option controls when the server uses the builtin handler to process special key combinations (such as Ctrl+Alt+Backspace). Normally the XKEYBOARD extension keymaps will provide mappings for each of the special key combinations, so the builtin han- dler is not needed unless the XKEYBOARD extension is disabled. The value of when can be Always, Never, or WhenNeeded. Default: Use the builtin handler only if needed. The server will scan the keymap for a mapping to the Terminate action and, if found, use XKEYBOARD for processing actions, otherwise the builtin handler will be used. Second sentance above. this was corrected by the following commit: commit 3a690598cf18c4cdc6aadd10a1ecf0772cacd34b Author: Alan Coopersmith alan.coopersm...@sun.com Date: Tue Dec 2 12:59:57 2008 -0800 Remove unused HandleSpecialKeys config option This should be in the 1.6 man page if I'm not mistaken. What server version are you using? Mind you, I've just spotted other issues in the current man page to that needs fixing too. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Touchscreen troubles
On Fri, Dec 11, 2009 at 10:41:18PM +0100, Petr Štetiar wrote: I'm trying to get working 22 resistive 5-wire touchscreen with USB controller, it's ETT TC5UH[1]. I'm using Ubuntu 9.04 with Xorg server 1.6.0, evdev version 2.3.2 compiled manualy. I've set calibration[1] gathered using values from kernel printk. It kind of works, but only on half of the screen, top-lef part: crappy-ascii-art [x=284; y=279] [x=1846; y=230] [x=3633; y=189] +-+---+ |. / | | . / | | working part . / | | . / | [x=209; y=1914]+ . + [x=1352; y=1697] + [x=2697; y=1212] | . / | | . / not working | | . / part | | / | +-+---+ [x=165; y=3652] [x=875; y=3023][x=1693; y=2136] the evdev calibration won't help much with this, it addresses a different issue that doesn't apply for your device. the calibration principle in evdev is aimed at devices that report points within a rectangular area that's not the same as the one reported by the kernel. e.g. if the kernel reports 0/0 to 100/100 but the actual device reports 25/25 to 75/75 - that's what the calibration can fix. in your case, coordinates aren't strictly rectangular. top right has x of 3633, whereas bottom right has an x of 1693, approximately half of it. the Y coordinate is similar though not quite as extreme. This explains the cutoff, from evdev's POV the x coordinate 2697 (right-hand edge on your diagram) is a bit over half-way into the area (assuming 3633 as max). evdev would map coordinates in the bottom right half to some 'random' coordinates into the top left half. evdev doesn't have any facilities yet to cope with the scaling needed for this device. You'd have to start implementing your own mapping system and plug it into evdev. sorry. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is HandleSpecialKeys expected to work when xkeyboard is disabled?
On Mon, Dec 14, 2009 at 08:46:20AM +1000, Peter Hutterer wrote: this was corrected by the following commit: commit 3a690598cf18c4cdc6aadd10a1ecf0772cacd34b Author: Alan Coopersmith alan.coopersm...@sun.com Date: Tue Dec 2 12:59:57 2008 -0800 Remove unused HandleSpecialKeys config option This should be in the 1.6 man page if I'm not mistaken. What server version are you using? 1.6.1 - from a distribution, not (yet) self compiled. /phx h=net$; rpm -q x11-server-xorg -i Name: x11-server-xorg Relocations: (not relocatable) Version : 1.6.1 Vendor: Mandriva Release : 5.7mdv2009.1 Build Date: Thu 01 Oct 2009 11:52:40 BST Install Date: Fri 02 Oct 2009 19:29:14 BST Build Host: titan.mandriva.com Group : System/X11Source RPM: x11-server-1.6.1-5.7mdv2009.1.src.rpm Size: 1932058 License: MIT Signature : DSA/SHA1, Thu 01 Oct 2009 11:58:14 BST, Key ID 9aa8d0d022458a98 Packager: Mandriva Linux Security Team secur...@mandriva.com URL : http://xorg.freedesktop.org Summary : X.org X11 server Description : x11-server-xorg is the new generation of X server from X.Org. h=net$; rpm -q x11-server-xorg -l /etc/X11/X /etc/pam.d/xserver /etc/security/console.apps/xserver /usr/bin/X /usr/bin/Xorg /usr/bin/Xwrapper /usr/share/man/man1/Xorg.1.lzma /usr/share/man/man1/Xserver.1.lzma /usr/share/man/man5/xorg.conf.5.lzma ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is HandleSpecialKeys expected to work when xkeyboard is disabled?
On Sun, Dec 13, 2009 at 05:25:10PM -0800, Derek Fawcus wrote: On Mon, Dec 14, 2009 at 08:46:20AM +1000, Peter Hutterer wrote: this was corrected by the following commit: commit 3a690598cf18c4cdc6aadd10a1ecf0772cacd34b Author: Alan Coopersmith alan.coopersm...@sun.com Date: Tue Dec 2 12:59:57 2008 -0800 Remove unused HandleSpecialKeys config option This should be in the 1.6 man page if I'm not mistaken. What server version are you using? 1.6.1 - from a distribution, not (yet) self compiled. you're right, just checked again, alan's commit didn't make the 1.6 branch. i nominated it, at least for the man page parts of that commit but I don't know if another 1.6 release is planned. Cheers, Peter ___ 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 d...@riga.lv: 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 wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Device Status: 0x (Bus Powered) Apparently it should have output a section entitled: HID Device Descriptor: and instead I got ** UNRECOGNIZED: 09 21 00 01 00 01 22 ea 00. Do you get the same?
[ANNOUNCE] xf86-input-synaptics 1.2.1
The first stable update to the X.Org synaptics touchpad driver is now available. The main fix addresses a possible deadlock caused by allocations during signal handling along. The rest is just man page fixes and a simple change for consistency. Adam Jackson (1): Don't destroy the timer on DeviceOff. Peter Hutterer (4): man: update manpage for new tap ordering synclient: fix man page typo Always make the input buffer size 200 synaptics 1.2.1 git tag: xf86-input-synaptics-1.2.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.2.1.tar.bz2 MD5: 29a6f9da5123149e4abc8ff83880ed5c xf86-input-synaptics-1.2.1.tar.bz2 SHA1: ffdad38384f3dcbf650d1db7e3d75ed46935a2c6 xf86-input-synaptics-1.2.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.2.1.tar.gz MD5: aab3ba9e4c21edd9572b3f827e0e4667 xf86-input-synaptics-1.2.1.tar.gz SHA1: d6e947811f958eb5a316354b1ab2f84c9a753d4e xf86-input-synaptics-1.2.1.tar.gz pgpvnFrtURi1i.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
