Launchpad has imported 61 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=473144.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2008-11-26T19:15:15+00:00 Jurgen wrote: Created attachment 324781 dmesg output with detected USB touchscreen Description of problem: USB touchscreen driver/pen is not automatically added/usable Version-Release number of selected component (if applicable): xorg-x11-drv-evdev-2.07-3.fc10.i386 How reproducible: Always Steps to Reproduce: 1. Boot system into X 2. Try using the pen 3. Actual results: Pen / touchscreen not usable Expected results: Pen / touchscreen automatically configured and usable Additional info: The proper usb device is detected by the kernel (see also attached dmesg output) but not used by X. usb 4-2: new full speed USB device using uhci_hcd and address 2 usb 4-2: configuration #1 chosen from 1 choice usb 4-2: New USB device found, idVendor=0eef, idProduct=0001 usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 4-2: Product: USB TouchController usb 4-2: Manufacturer: eGalax Inc. <snip> input: eGalax Inc. USB TouchController as /devices/pci0000:00/0000:00:1d.2/usb4/4-2/4-2:1.0/input/input7 input,hiddev96,hidraw2: USB HID v2.10 Pointer [eGalax Inc. USB TouchController] on usb-0000:00:1d.2-2 Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/0 ------------------------------------------------------------------------ On 2008-11-26T19:16:16+00:00 Jurgen wrote: Created attachment 324782 Xorg.0.log Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/1 ------------------------------------------------------------------------ On 2008-12-15T23:20:02+00:00 Peter wrote: Please attach the output of lshal. I'm pretty sure this is an issue with the kernel or hal not providing the right capability lists. Please download http://people.freedesktop.org/~whot/evtest.c, compile it with "gcc -o evtest evtest.c" and then run it as root with "./evtest /dev/input/eventX" where X is the number for the device. You can get the number by looking at /proc/bus/input/devices. Then attach the output of evtest here. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/2 ------------------------------------------------------------------------ On 2008-12-16T16:55:03+00:00 Jurgen wrote: Created attachment 327132 Output of evtest /dev/input/event7 Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/3 ------------------------------------------------------------------------ On 2008-12-16T16:55:39+00:00 Jurgen wrote: Created attachment 327133 Output from lshal Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/4 ------------------------------------------------------------------------ On 2008-12-16T16:56:15+00:00 Jurgen wrote: Created attachment 327134 Output from cat /proc/bus/input/devices Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/5 ------------------------------------------------------------------------ On 2008-12-16T16:57:24+00:00 Jurgen wrote: I've attached the requested info. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/6 ------------------------------------------------------------------------ On 2008-12-17T04:26:15+00:00 Peter wrote: This is actually a HAL issue (two separate ones). Please try the packages from http://koji.fedoraproject.org/scratch/whot/task_1002708/ and let me know how it goes. If it doesn't work, please attach the output from lshal again. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/7 ------------------------------------------------------------------------ On 2008-12-18T17:47:36+00:00 Jurgen wrote: Created attachment 327343 lshal output from updated hal Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/8 ------------------------------------------------------------------------ On 2008-12-18T17:48:13+00:00 Jurgen wrote: Created attachment 327344 Xorg.0.log with updated hal Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/9 ------------------------------------------------------------------------ On 2008-12-18T17:51:53+00:00 Jurgen wrote: I've installed the updated hal packages from koji. The last lines from the Xorg.0.log file show that the proper touch device is found, unfortunately the touchscreen still does not work. Excerpt from Xorg.0.log: (**) eGalax Inc. USB TouchController: always reports core events (**) eGalax Inc. USB TouchController: Device: "/dev/input/event7" (II) eGalax Inc. USB TouchController: Found x and y absolute axes (II) eGalax Inc. USB TouchController: Found absolute touchpad (II) eGalax Inc. USB TouchController: Found mouse buttons (II) eGalax Inc. USB TouchController: Configuring as mouse (II) XINPUT: Adding extended input device "eGalax Inc. USB TouchController" (type: MOUSE) Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/10 ------------------------------------------------------------------------ On 2008-12-19T01:30:39+00:00 Peter wrote: Reassigning to kernel. The device announces 4 axes, ABS_X, Y, Z and RX. The events only ever come through for Z and RX, no x/y information. Unless the kernel driver is fixed to send x/y information there isn't much we can do in X. I'll get the hal packages in in the meantime so once the kernel driver is fixed, it should "just work". Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/11 ------------------------------------------------------------------------ On 2009-01-24T23:30:10+00:00 Max wrote: I am using kernel 2.6.27.9-159.fc10.i686 and it seems that the kernel is no longer recognizing my usb touchscreen The output from dmesg is usb 3-1: new low speed USB device using uhci_hcd and address 4 usb 3-1: string descriptor 0 read error: -32 usb 3-1: string descriptor 0 read error: -32 usb 3-1: configuration #1 chosen from 1 choice usb 3-1: string descriptor 0 read error: -32 usb 3-1: New USB device found, idVendor=0eef, idProduct=0001 usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usbcore: registered new interface driver usbtouchscreen and /proc/bus/usb/devices says T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=1.5 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0eef ProdID=0001 Rev= 1.00 C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 44mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=(none) E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=5ms lsusb gives Bus 003 Device 004: ID 0eef:0001 D-WAV Scientific Co., Ltd eGalax TouchScreen the device is not listed in /proc/bus/input/devices Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/12 ------------------------------------------------------------------------ On 2009-03-13T14:40:08+00:00 Jurgen wrote: With the latest rawhide the touch still won't work out of the box. I have attached a new Xorg.0.log and dmesg output files. In contrast to Max (comment #12) the device show up in /proc/bus/input/devices as input10. It looks like the xorg touch driver no longer recognized my touchscreen (??): (II) config/hal: Adding input device eGalax Inc. USB TouchController (II) LoadModule: "synaptics" (II) Loading /usr/lib/xorg/modules/input//synaptics_drv.so (II) Module synaptics: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.1.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 4.0 (II) Synaptics touchpad driver version 1.1.0 (**) Option "Device" "/dev/input/event10" (--) eGalax Inc. USB TouchController: no supported touchpad found (**) eGalax Inc. USB TouchController: always reports core events (II) XINPUT: Adding extended input device "eGalax Inc. USB TouchController" (type: TOUCHPAD) (**) eGalax Inc. USB TouchController: (accel) keeping acceleration scheme 1 (**) eGalax Inc. USB TouchController: (accel) filter chain progression: 2.00 (**) eGalax Inc. USB TouchController: (accel) filter stage 0: 20.00 ms (**) eGalax Inc. USB TouchController: (accel) set acceleration profile 0 (--) eGalax Inc. USB TouchController: no supported touchpad found Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/13 ------------------------------------------------------------------------ On 2009-03-13T14:41:17+00:00 Jurgen wrote: Created attachment 335095 Xorg.0.log from latest rawhide (March 13) Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/14 ------------------------------------------------------------------------ On 2009-03-13T14:46:07+00:00 Jurgen wrote: Created attachment 335096 dmesg from latest rawhide kernel Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/15 ------------------------------------------------------------------------ On 2009-03-13T19:12:03+00:00 Max wrote: Some info on my initial problem after working with the driver developer it was fixed in the kernel see here for more details http://patchwork.kernel.org/patch/6107/ Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/16 ------------------------------------------------------------------------ On 2009-03-14T08:06:32+00:00 Jurgen wrote: (In reply to comment #16) > Some info on my initial problem > after working with the driver developer it was fixed in the kernel > see here for more details http://patchwork.kernel.org/patch/6107/ I guess that with 2.6.29 the mentioned kernel patch is included? From my (comment #13) it looks like X no long has the evtouch driver we need. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/17 ------------------------------------------------------------------------ On 2009-03-14T10:50:05+00:00 Max wrote: you can choose betwween different Xorg drivers I tested -evdev comes with Xorg but calibration is not working for me but should be fixed soon -evtouch not part of fedora and drag n drop is not working for me -properitary driver eGalax I currently use this until evdev is fixed - has working calibration and drag n drop support Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/18 ------------------------------------------------------------------------ On 2009-04-11T00:42:07+00:00 Chuck wrote: (In reply to comment #17) > (In reply to comment #16) > > Some info on my initial problem > > after working with the driver developer it was fixed in the kernel > > see here for more details http://patchwork.kernel.org/patch/6107/ > > I guess that with 2.6.29 the mentioned kernel patch is included? From my > (comment #13) it looks like X no long has the evtouch driver we need. Yes, that patch went into 2.6.29-rc7. Can the kernel bug be closed now? Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/19 ------------------------------------------------------------------------ On 2009-04-11T22:26:38+00:00 Max wrote: As far as it fixes the problem that some touchscreens like mine were not correctly recognized from the kernel - yes Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/20 ------------------------------------------------------------------------ On 2009-04-14T14:16:26+00:00 Matěj wrote: Reporter? Any opinions on 2.6.29 kernel? Can you still reproduce the issue with the latest upgrades in Fedora/Rawhide? Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/21 ------------------------------------------------------------------------ On 2009-04-14T16:02:19+00:00 Jurgen wrote: I will retest as soon as I am able to update my system (https://bugzilla.redhat.com/show_bug.cgi?id=473142) Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/22 ------------------------------------------------------------------------ On 2009-04-15T17:53:28+00:00 Jurgen wrote: Could you elaborate what should be fixed with the 2.6.29 kernel? I managed to update the system to the current rawhide but for me there looks to be no difference. Xorg.0.log still shows the same messages as with my comment #14. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/23 ------------------------------------------------------------------------ On 2009-04-15T21:00:02+00:00 Max wrote: As I described bevor the kernel patch fixes only the problem that certain touchscreens are not recognized from the kernel as "touchscreen" and therefore cannot be used. This is not depending on Xorg This fixes nothing for the Xorg driver situation which is currently not very good since evdev support for touchscreens is missing e.g. calibration I described above the possible drivers you can use in Xorg. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/24 ------------------------------------------------------------------------ On 2009-04-16T00:57:14+00:00 Peter wrote: (In reply to comment #24) > This fixes nothing for the Xorg driver situation which > is currently not very good since evdev support for > touchscreens is missing e.g. calibration fwiw, man evdev(4) Evdev Axis Calibration 4 32-bit values, order min-x, max-x, min-y, max-y or 0 values to disable run-time axis calibration. This feature is required for devices that need to scale to a different coordinate system than originally reported to the X server, such as touchscreens that require run-time cali- bration. xinput --set-int-prop "My Device" "Evdev Axis Calibration" 32 0 10 20 30 for example calibrates your touchscreen at runtime if the actual range is 0-10 on x and 20-30 on y. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/25 ------------------------------------------------------------------------ On 2009-04-16T10:25:11+00:00 Max wrote: yes I know this man page :) But this is actually "brand new" and at least on my fedora 10 this enhancements have not been included in the Xorg package AFAIK e.g. the xinput has no --set-int-prop parameter support Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/26 ------------------------------------------------------------------------ On 2009-04-17T00:48:18+00:00 Peter wrote: right, f10 doesn't have it, but f11 does (this bug is rawhide, hence my assumption). the version in F10 still has the same options, but they cannot be changed at runtime. So you'd have to get the values once and then modify the configuration, and then restart the server. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/27 ------------------------------------------------------------------------ On 2009-05-14T12:58:26+00:00 jordan wrote: I have seen this problem as well.. the input events are on RX/Z not the X/Y axis. I had to modify the evtouch X driver to handle RX/Z events as well. The real problem is in drivers/usb/hid-input.c. The egalax 0eef:0001 touchscreen reports 2 x/y axes but only the 2nd one is active. When the 2nd set is detected, the following code is the culprit: while (usage->code <= max && test_and_set_bit(usage->code, bit)) { usage->code = find_next_zero_bit(bit, max + 1, usage->code); } Since abs_x and abs_y are already set in bit, it finds the next two open holes at rx/z. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/28 ------------------------------------------------------------------------ On 2009-06-09T09:56:44+00:00 Bug wrote: This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/29 ------------------------------------------------------------------------ On 2009-06-14T02:29:42+00:00 Matt wrote: I encountered this bug when I upgraded to Fedora 11. Can you comment on which kernel is supposed to have addressed this? I have kernel-2.6.29.4-167.fc11.x86_64. In /var/log/Xorg.0.log I see: (II) config/hal: Adding input device eGalax INC. USB TouchController (II) Synaptics touchpad driver version 1.1.0 (**) Option "Device" "/dev/input/event7" (**) Option "TapButton1" "1" (**) Option "TapButton2" "3" (**) Option "TapButton3" "2" (--) eGalax INC. USB TouchController: no supported touchpad found (EE) eGalax INC. USB TouchController Unable to query/initialize Synaptics hardware. (EE) PreInit failed for input device "eGalax INC. USB TouchController" (II) UnloadModule: "synaptics" Can you also comment on how you got the egalax driver working? After installing the module, I have this in my xorg.conf file: Section "InputDevice" Identifier "EETI" Driver "egalax" Option "Device" "usbauto" Option "Parameters" "/var/lib/eeti.param" Option "ScreenNo" "0" EndSection And in the Xorg log file: (II) LoadModule: "egalax" (II) Loading /usr/lib64/xorg/modules/input//egalax_drv.so (II) Module egalax: vendor="X.Org Foundation" compiled for 1.6.0, module version = 2.6.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 4.0 ... (**) Option "SendCoreEvents" (**) egalax: always reports core events (**) egalax X device name: egalax (II) HID Touch Controller @ /dev/hidraw0 (**) egalaxHistroSize=10 (**) Option "ScreenNo" "0" (**) egalax associated screen: 0 (**) egalaxParameter=/var/lib/eeti.param (II) XINPUT: Adding extended input device "egalax" (type: egalax) But when I press the touchscreen the mouse moves erratically. Subsequent mouse input (for example from a touchpad) causes spurious clicks and the left button stops working. I noticed that something is adding a mouse device handler to the touchscreen: cat /proc/bus/input/devices ... I: Bus=0003 Vendor=0eef Product=0001 Version=0210 N: Name="eGalax INC. USB TouchController" P: Phys=usb-0000:00:0b.1-2.3/input0 S: Sysfs=/devices/pci0000:00/0000:00:0b.1/usb1/1-2/1-2.3/1-2.3:1.0/input/input7 U: Uniq= H: Handlers=mouse2 event7 B: EV=1b B: KEY=401 30000 0 0 0 0 B: ABS=f B: MSC=10 ... How can I disable this? Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/30 ------------------------------------------------------------------------ On 2009-06-14T22:38:41+00:00 Max wrote: I can only comment your second question. One possible reason for this may be that there is more then one input handler for the touchscreen in X In my case I had to disable the evdev driver using a hal fdi file to choose the eGalax driver instead Do you have a also an entry for the evdev touchscreen driver in your Xorg.log? Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/31 ------------------------------------------------------------------------ On 2009-06-15T02:46:17+00:00 Matt wrote: It looks like evdev comes up for my keyboard and handles power button events. I don't see anything for the touchscreen. I think the problem is that the touchscreen is also giving input on /dev/input/mouse2 (as seen above) and /dev/input/mice. When I do od /dev/input/mouse2 or od /dev/input/mice I see some data coming through when I touch the touchscreen. I think Xorg is listening to mouse2 or mice as a mouse, and misinterpreting the touchscreen input. I think the touchscreen can't run through the kernel mouse driver. The confusing part is, I don't see anything specific to mouse2 or mice in xorg.conf, or in Xorg.0.log, or in dmesg. Could you post the relevant lines from your hal fdi file to get the egalax xorg driver to load (rather than synaptics?). Thanks! Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/32 ------------------------------------------------------------------------ On 2009-06-15T03:29:13+00:00 Peter wrote: except if explicity configured, the X server doesn't listen to /dev/input/mice or mouseX, so that's unlikely the problem. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/33 ------------------------------------------------------------------------ On 2009-06-15T05:20:05+00:00 Matt wrote: Ok, I agree with you. I can remove the egalax driver from xorg.conf and the touchscreen doesn't create any input events when touched. I'm trying to setup an fdi file like Max suggested. My first goal is to get xorg to stop trying to load the synaptics driver for the eGalax touchscreen. I edited /usr/share/hal/fdi/policy/20thirdparty/10-synaptics.fdi (I know I'm supposed to put it in /etc/hal/fdi/... so it doesn't get overwritten, but I'd rather just have a single copy of the file while I'm testing). The file starts out like this (comments removed): <deviceinfo version="0.2"> <device> <match key="info.capabilities" contains="input.touchpad"> <merge key="input.x11_driver" type="string">synaptics</merge> </match> </device> </deviceinfo> I changed it to this: <deviceinfo version="0.2"> <device> <match key="info.capabilities" contains="input.touchpad"> <match key="info.product" contains="Synaptics TouchPad"> <merge key="input.x11_driver" type="string">synaptics</merge> </match> </match> </device> </deviceinfo> My actual synaptics touchpad is identified by xorg/hal as: (II) config/hal: Adding input device SynPS/2 Synaptics TouchPad And the touchscreen is identified by xorg/hal as: (II) config/hal: Adding input device eGalax INC. USB TouchController Yet with the above changed fdi file I still get xorg trying to use the synaptics driver for the eGalax device: (II) config/hal: Adding input device eGalax INC. USB TouchController (II) Synaptics touchpad driver version 1.1.0 (**) Option "Device" "/dev/input/event7" (--) eGalax INC. USB TouchController: no supported touchpad found (EE) eGalax INC. USB TouchController Unable to query/initialize Synaptics hardware. (EE) PreInit failed for input device "eGalax INC. USB TouchController" (II) UnloadModule: "synaptics" (EE) config/hal: NewInputDeviceRequest failed (8) I know the fdi file is being parsed, because I can add extra Synaptics options there, and they show up for both the eGalax and synaptics devices in the xorg server log. Do you see a problem with what I'm doing? Thanks again for your help. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/34 ------------------------------------------------------------------------ On 2009-06-15T10:02:20+00:00 Max wrote: Unfortunately dont have the fdi file by hand and I also forgot the exact contents :) but I can mail it to you in the next days Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/35 ------------------------------------------------------------------------ On 2009-07-15T18:26:10+00:00 Ritchey wrote: I have the same problem, a Planar PT1910MX touch screen with eGalax USB and am eagerly awaiting a solution! In regards to the touch screen calibration, there is a utility called evtouch used by the Ubuntu community. More info here: http://stz-softwaretechnik.com/~ke/touchscreen/lifebook-2.6.html and here: http://ubuntuforums.org/showthread.php?t=482574 Please feel free to contact me if you need anyone to do some testing! Thanks! Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/36 ------------------------------------------------------------------------ On 2009-07-16T21:36:41+00:00 Julian wrote: is there any chance of seeing that fdi file? Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/37 ------------------------------------------------------------------------ On 2009-07-16T21:45:37+00:00 Max wrote: You mean the one that I mentioned in #35? here it is <?xml version="1.0" encoding="UTF-8"?> <!-- -*- SGML -*- --> <deviceinfo version="0.2"> <device> <match key="info.product" contains="USB Touchscreen 0eef:0001"> <match key="info.capabilities" contains="input"> <merge key="input.x11_driver" type="string">egalax</merge> <merge key="input.x11_device" type="string">usbauto</merge> <merge key="input.x11_parameters" type="string">/var/lib/eeti.param</merge> </match> </match> </device> </deviceinfo> I use it in a file named 50-eGalax-etti.fdi placed in /etc/fdi/policy This inhibits for me that the evdev driver is loaded for the touchscreen which leads to double events IMHO. Dont know if this helps in the synapic case also Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/38 ------------------------------------------------------------------------ On 2009-09-20T20:41:13+00:00 Matt wrote: For whatever reason, my egalax touchscreen gets confused with a synaptics touchpad, not the evdev driver. I had to change the above fdi file - specifically the "contains" part didn't match my device: <?xml version="1.0" encoding="UTF-8"?> <!-- -*- SGML -*- --> <deviceinfo version="0.2"> <device> <match key="info.product" contains="eGalax INC. USB TouchController"> <match key="info.capabilities" contains="input"> <merge key="input.x11_driver" type="string">egalax</merge> <merge key="input.x11_device" type="string">usbauto</merge> <merge key="input.x11_parameters" type="string">/etc/egalax.cal</merge> </match> </match> </device> </deviceinfo> I put it in /etc/hal/fdi/policy, which is probably what the above post was referring to. After doing this, the touchscreen is loaded in xorg via hal using the egalax driver. I still have a problem where I can list the device in hal, and input.x11_parameters says /etc/egalax.cal, but the xorg driver doesn't seem to get this information, and is looking for the calibration file in the default location /var/lib/eeti.param. #hal-device /org/freedesktop/Hal/devices/usb_device_eef_1_noserial_if0_logicaldev_input udi = '/org/freedesktop/Hal/devices/usb_device_eef_1_noserial_if0_logicaldev_input' input.x11_device = 'usbauto' (string) input.x11_parameters = '/etc/egalax.cal' (string) linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:0b.1/usb1/1-2/1-2.3/1-2.3:1.0/input/input7/event7' (string) input.product = 'eGalax INC. USB TouchController' (string) info.parent = '/org/freedesktop/Hal/devices/usb_device_eef_1_noserial_if0' (string) input.device = '/dev/input/event7' (string) info.capabilities = { 'input', 'input.touchpad' } (string list) info.subsystem = 'input' (string) info.product = 'eGalax INC. USB TouchController' (string) info.udi = '/org/freedesktop/Hal/devices/usb_device_eef_1_noserial_if0_logicaldev_input' (string) linux.device_file = '/dev/input/event7' (string) input.x11_driver = 'egalax' (string) info.category = 'input' (string) linux.hotplug_type = 2 (0x2) (int) linux.subsystem = 'input' (string) input.originating_device = '/org/freedesktop/Hal/devices/usb_device_eef_1_noserial_if0' (string) # grep egalax /var/log/Xorg.0.log (II) LoadModule: "egalax" (II) Loading /usr/lib64/xorg/modules/input//egalax_drv.so (II) Module egalax: vendor="X.Org Foundation" (**) egalax: always reports core events (**) egalax X device name: egalax (**) egalaxHistroSize=10 (**) egalax associated screen: 0 (**) egalax:Use Defualt Parameter file:/var/lib/eeti.param(**) egalax Rotation option is enabled. (II) XINPUT: Adding extended input device "egalax" (type: egalax) Also, I had more success with the latest beta driver (1.07) from eeti: http://home.eeti.com.tw/web20/eGalaxTouchDriver/linuxDriver.htm Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/39 ------------------------------------------------------------------------ On 2009-09-21T07:24:26+00:00 Max wrote: I guess the location /var/lib/eeti.param ist "hard-coded" and cannot be changed. The rest looks good IMHO Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/40 ------------------------------------------------------------------------ On 2009-10-17T09:14:50+00:00 Guy wrote: With the procedure in #39, I got my eGalax touchscreen working on an HP tx1000. Thanks! For anyone else trying to do this, it's worth mentioning that this caused two touchscreen devices to appear simultaneously. Since the two were slightly different in their calibration properties, the pointer jumped around erratically when the touchscreen was in use. After removing EETI's installation script changes xorg.conf, however, only one device remained. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/41 ------------------------------------------------------------------------ On 2010-01-26T02:15:34+00:00 Chris wrote: Updated information on bug report. * I have verified this is still an issue with Fedora 12 so can be bumped to that release number. A code review for linus's git shows same driver there so I'm guessing be a problem in rawhide as well. * The solution in comment #39 requires a binary blob as input driver that appears to understand kernel driver bug. I'm hoping to get a fix that lets open source xf86-input-evdev be used. * Kernel's drivers/hid-input.c still has logic mentioned in comment #28 in function hidinput_configure_usage(). I've not debuged yet to verify but code review leads me to believe it must be whats happening. 510 while (usage->code <= max && test_and_set_bit(usage->code, bit)) 511 usage->code = find_next_zero_bit(bit, max + 1, usage->code); If hardware, for what ever reason, reports two HID_GD_X and HID_GD_Y's then the second set will set usage->code to ABS_Y and ABS_RX. Seems a little strange logic. Later, in hidinput_hid_event(), the following code will use usage->code which has incorrect ABS_Y/ABS_RX values and xf86-input-evdev will see interrupt wrong. 582 input_event(input, usage->type, usage->code , hid_hat_to_axis[hat_dir].x); 583 input_event(input, usage->type, usage->code + 1, hid_hat_to_axis[hat_dir].y); I can help debug/fix but need someone to verify why above logic is there and if we can skip the while() at least for HID_UP_GENDESK cases or even the more limited X/Y cases. I suspose we could add a hid-egalax.c quirks file for at least this known eGalax device (0eef:0001) with double X/Y axes reports. This was in HP tx1000 series which were decently popular in big boxes of 2007. * Once kernel bug is fixed, we still need to address 10-synaptics.fdi claiming eGalax and similar touch screens owned by hid-input. Something that affectively does this: <match key="info.capabilities" contains="input.touchpad"> <match key="info.product" contains="eGalax"> <merge key="input.x11_driver" type="string">evdev</merge> </match> </match> Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/42 ------------------------------------------------------------------------ On 2010-01-29T04:29:50+00:00 Chris wrote: I was able to get my eGalax touchscreen working with following work around. I don't know best fix to hid-input.c yet so instead I added a hack. I chose to hack xf86-input-evdev since its updated less then kernel and also hid-input is NOT a kernel module in Fedora and so harder to replace. First, I created the file /etc/hal/fdi/policy/11-evdev.fdi with contents listed in comment #42 so that xf86-input-evdev is used. Next, I also downloaded and applied below patch to xf86-input-evdev so that Z/RX were treated same as X/Y. And finally, I came up with following calibration values by using "evtest /dev/input/event7", tracing around border of screen, and monitoring min/max values reports for Z/RX values and used those as X/Y values instead: xinput --set-int prop 9 "Evdev Axis calibration" 32 48 3990 95 3990 *** evdev.c.orig 2010-01-28 21:13:58.153740219 -0600 --- evdev.c 2010-01-28 21:15:25.928480429 -0600 *************** *** 590,595 **** --- 590,603 ---- if (ev->code > ABS_MAX) return; + /* Hack to work around but in hid-input.c were double X/Y + * inputs cause second set to be mapped to Y/RX. + */ + if (ev->code == ABS_Z) + ev->code = ABS_X; + if (ev->code == ABS_RX) + ev->code = ABS_Y; + pEvdev->vals[pEvdev->axis_map[ev->code]] = value; if (ev->code == ABS_X) pEvdev->abs |= ABS_X_VALUE; Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/43 ------------------------------------------------------------------------ On 2010-02-01T05:48:58+00:00 Peter wrote: Does the kernel build available http://koji.fedoraproject.org/koji/taskinfo?taskID=1955391 work for you? On the box I've got on my desk ATM, it makes the pointer move but not yet click. Another patch is needed for that, either in the kernel or in evdev - not sure yet. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/44 ------------------------------------------------------------------------ On 2010-02-02T03:00:42+00:00 Chris wrote: Yes, the kernel in #44 worked nicely! Thank you much for the patch. (I hate when it turns out to be a simple change and I didn't figure it out myself). This kernel now creates two inputs instead of one. There is one input that is useless and assigned info.capabilities of input.mouse and input.x11_driver evdev. The good one still has info.capabilities of input.touchpad and input.x11_driver of synaptics (from 10-synaptics.fdi). So I still need my /etc/hal/fdi/policy/11-evdev.fdi override. This is just as well for me because I use it to also set calibration so that screen works even with GDM login. <?xml version="1.0" encoding="ISO-8859-1"?> <!-- 10-synaptics.fdi is claiming all input.touchpad's as its own. This file is meant to be loaded afterwards and to undo any wrong assignments it did. --> <deviceinfo version="0.2"> <device> <match key="info.capabilities" contains="input.touchpad"> <match key="info.product" contains="eGalax"> <merge key="input.x11_driver" type="string">evdev</merge> <merge key="input.x11_options.Calibration" type="string">32 3990 48 3990</merge> </match> </match> </device> </deviceinfo> Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/45 ------------------------------------------------------------------------ On 2010-02-21T05:17:47+00:00 Chris wrote: Another status update. It hasn't been previously mentioned in this report but if you use a stock Fedora xf86-input-evdev then left button presses do not work as you'd expect with a touch screen. But xf86-input-evdev-2.3.2 and rawhide's (Fedora 13-ish) xf86-input-evdev-2.3.99 contain fixes that let it work for HP TX1000 and HP TouchSmart devices. The required kernel fix in #44 for TX1000/Touchsmart is in a weird place. Its in a RPM for kernel-2.6.32 but that kernel is in neither Fedora 12 nor rawhide/Fedora 13. The Fedora patches to 2.6.32 haven't been forward ported to 2.6.33 yet. Once the kernel patches make it into rawhide, I think this bug report can be closed. There will be a remaining issue with HAL incorrectly mapping some touchscreens to synaptics but I don't think its worth tracking since HAL is unsupported and any fix can't be supported up stream. Touchscreen owners will need always to make a custom HAL .fdi file to calibrate the screen anyways and so can remap to evdev at same time. Calibration can't really be automated at this time. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/46 ------------------------------------------------------------------------ On 2010-04-27T12:22:59+00:00 Bug wrote: This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/50 ------------------------------------------------------------------------ On 2010-05-04T17:44:28+00:00 Ernesto wrote: Help! I upgraded my HP tx1000 to Fedora 13, and this bug turned into this: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/549447 . You can watch the exact same behaviour (every touch, even if it's accurately reported by xinput test, ends in the upper-left corner). That behaviour wasn't present with Fedora 12 (it worked with HAL and the rule above). Please, reopen against Fedora 13! Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/59 ------------------------------------------------------------------------ On 2010-05-04T19:41:43+00:00 Ernesto wrote: Let's kill this bug once and for all. My eGalax touchscreen gets detected as a tablet, but basically works. The catch is: Evdev detects four axes: Absolute X axis (always in coordinate 42), Absolute Y axis (always in coordinate 42), Absolute Z axis (registering motion flawlessly), and Rotary X axis (also registering motion flawlessly). The axes are swapped, guys. [root@faeris faeris]# xinput list-props 11 Device 'eGalax INC. USB TouchController': Device Enabled (115): 1 Device Accel Profile (237): 0 Device Accel Constant Deceleration (238): 1.000000 Device Accel Adaptive Deceleration (240): 1.000000 Device Accel Velocity Scaling (241): 10.000000 Evdev Axis Inversion (242): 0, 0 Evdev Axis Calibration (243): 32, 0, 1000, 0 Evdev Axes Swap (244): 0 Axis Labels (245): "Abs X" (233), "Abs Y" (234), "Abs Z" (235), "Abs Rotary X" (236) Button Labels (246): "Button Left" (116), "Button Unknown" (232), "Button Right" (118), "Button Wheel Up" (119), "Button Wheel Down" (120) Evdev Middle Button Emulation (247): 2 Evdev Middle Button Timeout (248): 50 Evdev Wheel Emulation (249): 0 Evdev Wheel Emulation Axes (250): 4, 5, 0, 0 Evdev Wheel Emulation Inertia (251): 10 Evdev Wheel Emulation Timeout (252): 200 Evdev Wheel Emulation Button (253): 4 Evdev Drag Lock Buttons (254): 0 When I run xinput test, Abs X and Abs Y are always at 42, but Abs Z and Abs Rotary X are registering accurately the motion. Also, the screen answers to clicks. What can I do to invert axes, so that X can move my pointer with Z and Rotary X (basically a workaround), or patching something so that Z and Rotary X come to be X and Y (the real fix)? This is also biting Ubuntu, so, I think it's upstream, and the evdev kernel driver is reading funky data from my touchscreen. This mail chain in the evdev list might be enlightening. http://www.mail-archive.com/xorg@lists.freedesktop.org/msg09730.html Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/60 ------------------------------------------------------------------------ On 2010-05-04T19:45:38+00:00 Ernesto wrote: The result of an xinput test 11 run. Abs X Abs Y Abs Z Z Rotate motion a[0]=42 a[1]=42 a[2]=784 a[3]=1380 motion a[0]=42 a[1]=42 a[2]=815 a[3]=1392 motion a[0]=42 a[1]=42 a[2]=847 a[3]=1404 motion a[0]=42 a[1]=42 a[2]=878 a[3]=1420 motion a[0]=42 a[1]=42 a[2]=909 a[3]=1437 motion a[0]=42 a[1]=42 a[2]=941 a[3]=1457 motion a[0]=42 a[1]=42 a[2]=972 a[3]=1480 motion a[0]=42 a[1]=42 a[2]=1004 a[3]=1506 motion a[0]=42 a[1]=42 a[2]=1035 a[3]=1534 motion a[0]=42 a[1]=42 a[2]=1065 a[3]=1566 motion a[0]=42 a[1]=42 a[2]=1095 a[3]=1600 motion a[0]=42 a[1]=42 a[2]=1125 a[3]=1637 motion a[0]=42 a[1]=42 a[2]=1154 a[3]=1676 motion a[0]=42 a[1]=42 a[2]=1182 a[3]=1719 motion a[0]=42 a[1]=42 a[2]=1211 a[3]=1764 motion a[0]=42 a[1]=42 a[2]=1239 a[3]=1811 motion a[0]=42 a[1]=42 a[2]=1268 a[3]=1859 motion a[0]=42 a[1]=42 a[2]=1297 a[3]=1908 motion a[0]=42 a[1]=42 a[2]=1326 a[3]=1956 motion a[0]=42 a[1]=42 a[2]=1355 a[3]=2006 motion a[0]=42 a[1]=42 a[2]=1387 a[3]=2056 motion a[0]=42 a[1]=42 a[2]=1421 a[3]=2105 motion a[0]=42 a[1]=42 a[2]=1455 a[3]=2149 motion a[0]=42 a[1]=42 a[2]=1489 a[3]=2194 motion a[0]=42 a[1]=42 a[2]=1524 a[3]=2235 motion a[0]=42 a[1]=42 a[2]=1562 a[3]=2273 motion a[0]=42 a[1]=42 a[2]=1600 a[3]=2309 motion a[0]=42 a[1]=42 a[2]=1639 a[3]=2344 motion a[0]=42 a[1]=42 a[2]=1679 a[3]=2376 motion a[0]=42 a[1]=42 a[2]=1720 a[3]=2407 motion a[0]=42 a[1]=42 a[2]=1763 a[3]=2437 motion a[0]=42 a[1]=42 a[2]=1809 a[3]=2465 motion a[0]=42 a[1]=42 a[2]=1856 a[3]=2488 motion a[0]=42 a[1]=42 a[2]=1902 a[3]=2511 motion a[0]=42 a[1]=42 a[2]=1951 a[3]=2530 You get the idea. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/61 ------------------------------------------------------------------------ On 2010-05-04T20:18:29+00:00 Ernesto wrote: Also, booting with vmlinuz-2.6.32.12-114.fc12.x86_64 (the latest Fedora 12 kernel) under my Fedora 13 system makes my touchscreen work. So, this is definitely a kernel bug, with the fix already in that kernel. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/62 ------------------------------------------------------------------------ On 2010-05-05T02:13:45+00:00 Chris wrote: My tx1000 got toasted during an upgrade to Fedora 13 beta. An ACPI bug caused it to overheat and hit the known design flaw with video on those. So I can't contribute much more to this. But I can point out that there is a Fedora-only patch in kernels 2.6.32 series that Fedora 12 finally started using. The patch never made it upstream. Looking at linus git as of this post, I see no HID_QUIRK_MULTI_INPUT quirk listed for the tx1000's listed in drivers/hid/usbhid/hid-quirks.c . What that would do is cause kernel to create 2 input devices instead of only one. This causes for x/y/z/rx values for single device to be broken in two and x/y on first and x/y again on second. One of those two inputs become effectively unused. Perhaps someone on this bug report chain can comment about forward porting the Fedora-only patch from 2.6.32 to the 2.6.33 series kernels and also submitting upstream? The rest of the story in this bug report is specific to Fedora 11/12 and its related to HAL fdi files which are no longer meaningful in Fedora 13 timeframe. I'd vote to close this bug report and open up new reports as needed to discuss any needed enhancements to xorg.conf.d files. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/63 ------------------------------------------------------------------------ On 2010-05-05T04:24:54+00:00 Ernesto wrote: Chris, if you were closer to Chile I'd recommend you a good technician who fixed that damned issue for me once and for all :(. How can I apply that patch? Is there any kernel parameter I can set, or a quirk I can force? If I were to guide myself by the title of this bug, I don't agree about closing this bug. We are so close to a real fix! Once we have the forward port, I agree we should move on and declare this bug fixed. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/64 ------------------------------------------------------------------------ On 2010-05-05T15:44:54+00:00 Ritchey wrote: It's working!! I switched over to Ubuntu Lucid Lynx! Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/66 ------------------------------------------------------------------------ On 2010-05-06T00:48:16+00:00 Ernesto wrote: https://patchwork.kernel.org/patch/76210/ Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/67 ------------------------------------------------------------------------ On 2010-05-07T11:19:13+00:00 Ernesto wrote: Reconfirmed: touchscreen works by adding usbhid.quirks=0xeef:0x1:0x40 to the boot line. 0xeef: eGalax (manufacturer hex code) 0x1: product code 0x40: MULTI quirk. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/68 ------------------------------------------------------------------------ On 2010-05-10T04:52:05+00:00 Peter wrote: Moving to F-13. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/71 ------------------------------------------------------------------------ On 2010-05-10T22:12:18+00:00 Peter wrote: Ben committed this patch to the F-13 kernel and the patch is now committed upstream too. So the next kernel update should fix this issue. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/72 ------------------------------------------------------------------------ On 2010-05-17T22:29:17+00:00 Ernesto wrote: We can close this now. The latest kernel (2.6.33 rev -95) solved the problem. We can make a proper fix for this later, but this is working, so, please, close this bug as WORKSFORME to properly track the status of eGalax support under Linux. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/73 ------------------------------------------------------------------------ On 2010-05-17T22:57:37+00:00 Peter wrote: thanks, closing as fixed then. Sorry about the delay, the patch fell under the table. Reply at: https://bugs.launchpad.net/fedora/+source/xserver-xorg-input- evdev/+bug/549447/comments/74 ** Changed in: xserver-xorg-input-evdev (Fedora) Status: Unknown => Fix Released ** Changed in: xserver-xorg-input-evdev (Fedora) Importance: Unknown => Medium ** Bug watch added: Red Hat Bugzilla #473142 https://bugzilla.redhat.com/show_bug.cgi?id=473142 -- You received this bug notification because you are a member of Ubuntu-X, which is subscribed to xserver-xorg-input-evdev in Ubuntu. https://bugs.launchpad.net/bugs/549447 Title: eGalax touchscreen configured as tablet To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/549447/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-x-swat Post to : ubuntu-x-swat@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-x-swat More help : https://help.launchpad.net/ListHelp
