Bug 473144

Summary: touchscreen (driver) not automatically configured/usable
Product: [Fedora] Fedora Reporter: Jurgen Kramer <gtmkramer>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 13CC: alejandronova, aquarichy, chris, guy.cohen, jewelsofthought, jordan_hargrave, kernel-maint, matthew.hirsch, max.weninger, peter.hutterer, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: kernel-2.6.33.4-95 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-05-17 18:57:37 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
dmesg output with detected USB touchscreen
none
Xorg.0.log
none
Output of evtest /dev/input/event7
none
Output from lshal
none
Output from cat /proc/bus/input/devices
none
lshal output from updated hal
none
Xorg.0.log with updated hal
none
Xorg.0.log from latest rawhide (March 13)
none
dmesg from latest rawhide kernel none

Description Jurgen Kramer 2008-11-26 14:15:15 EST
Created attachment 324781 [details]
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
Comment 1 Jurgen Kramer 2008-11-26 14:16:16 EST
Created attachment 324782 [details]
Xorg.0.log
Comment 2 Peter Hutterer 2008-12-15 18:20:02 EST
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.
Comment 3 Jurgen Kramer 2008-12-16 11:55:03 EST
Created attachment 327132 [details]
Output of evtest /dev/input/event7
Comment 4 Jurgen Kramer 2008-12-16 11:55:39 EST
Created attachment 327133 [details]
Output from lshal
Comment 5 Jurgen Kramer 2008-12-16 11:56:15 EST
Created attachment 327134 [details]
Output from cat /proc/bus/input/devices
Comment 6 Jurgen Kramer 2008-12-16 11:57:24 EST
I've attached the requested info.
Comment 7 Peter Hutterer 2008-12-16 23:26:15 EST
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.
Comment 8 Jurgen Kramer 2008-12-18 12:47:36 EST
Created attachment 327343 [details]
lshal output from updated hal
Comment 9 Jurgen Kramer 2008-12-18 12:48:13 EST
Created attachment 327344 [details]
Xorg.0.log with updated hal
Comment 10 Jurgen Kramer 2008-12-18 12:51:53 EST
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)
Comment 11 Peter Hutterer 2008-12-18 20:30:39 EST
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".
Comment 12 Max Weninger 2009-01-24 18:30:10 EST
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
Comment 13 Jurgen Kramer 2009-03-13 10:40:08 EDT
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
Comment 14 Jurgen Kramer 2009-03-13 10:41:17 EDT
Created attachment 335095 [details]
Xorg.0.log from latest rawhide (March 13)
Comment 15 Jurgen Kramer 2009-03-13 10:46:07 EDT
Created attachment 335096 [details]
dmesg from latest rawhide kernel
Comment 16 Max Weninger 2009-03-13 15:12:03 EDT
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/
Comment 17 Jurgen Kramer 2009-03-14 04:06:32 EDT
(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.
Comment 18 Max Weninger 2009-03-14 06:50:05 EDT
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
Comment 19 Chuck Ebbert 2009-04-10 20:42:07 EDT
(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?
Comment 20 Max Weninger 2009-04-11 18:26:38 EDT
As far as it fixes the problem that some touchscreens like mine
were not correctly recognized from the kernel - yes
Comment 21 Matěj Cepl 2009-04-14 10:16:26 EDT
Reporter? Any opinions on 2.6.29 kernel? Can you still reproduce the issue with the latest upgrades in Fedora/Rawhide?
Comment 22 Jurgen Kramer 2009-04-14 12:02:19 EDT
I will retest as soon as I am able to update my system (https://bugzilla.redhat.com/show_bug.cgi?id=473142)
Comment 23 Jurgen Kramer 2009-04-15 13:53:28 EDT
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.
Comment 24 Max Weninger 2009-04-15 17:00:02 EDT
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.
Comment 25 Peter Hutterer 2009-04-15 20:57:14 EDT
(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.
Comment 26 Max Weninger 2009-04-16 06:25:11 EDT
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
Comment 27 Peter Hutterer 2009-04-16 20:48:18 EDT
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.
Comment 28 jordan hargrave 2009-05-14 08:58:26 EDT
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.
Comment 29 Bug Zapper 2009-06-09 05:56:44 EDT
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
Comment 30 Matt Hirsch 2009-06-13 22:29:42 EDT
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?
Comment 31 Max Weninger 2009-06-14 18:38:41 EDT
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?
Comment 32 Matt Hirsch 2009-06-14 22:46:17 EDT
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!
Comment 33 Peter Hutterer 2009-06-14 23:29:13 EDT
except if explicity configured, the X server doesn't listen to /dev/input/mice or mouseX, so that's unlikely the problem.
Comment 34 Matt Hirsch 2009-06-15 01:20:05 EDT
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.
Comment 35 Max Weninger 2009-06-15 06:02:20 EDT
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
Comment 36 Ritchey Mulhollem 2009-07-15 14:26:10 EDT
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!
Comment 37 Julian Gordon 2009-07-16 17:36:41 EDT
is there any chance of seeing that fdi file?
Comment 38 Max Weninger 2009-07-16 17:45:37 EDT
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
Comment 39 Matt Hirsch 2009-09-20 16:41:13 EDT
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
Comment 40 Max Weninger 2009-09-21 03:24:26 EDT
I guess the location /var/lib/eeti.param ist "hard-coded"
and cannot be changed.
The rest looks good IMHO
Comment 41 Guy Cohen 2009-10-17 05:14:50 EDT
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.
Comment 42 Chris Bagwell 2010-01-25 21:15:34 EST
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>
Comment 43 Chris Bagwell 2010-01-28 23:29:50 EST
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;
Comment 44 Peter Hutterer 2010-02-01 00:48:58 EST
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.
Comment 45 Chris Bagwell 2010-02-01 22:00:42 EST
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>
Comment 46 Chris Bagwell 2010-02-21 00:17:47 EST
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.
Comment 47 Bug Zapper 2010-04-27 08:22:59 EDT
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
Comment 48 Ernesto Manríquez 2010-05-04 13:44:28 EDT
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!
Comment 49 Ernesto Manríquez 2010-05-04 15:41:43 EDT
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
Comment 50 Ernesto Manríquez 2010-05-04 15:45:38 EDT
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.
Comment 51 Ernesto Manríquez 2010-05-04 16:18:29 EDT
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.
Comment 52 Chris Bagwell 2010-05-04 22:13:45 EDT
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.
Comment 53 Ernesto Manríquez 2010-05-05 00:24:54 EDT
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.
Comment 54 Ritchey Mulhollem 2010-05-05 11:44:54 EDT
It's working!!  I switched over to Ubuntu Lucid Lynx!
Comment 55 Ernesto Manríquez 2010-05-05 20:48:16 EDT
https://patchwork.kernel.org/patch/76210/
Comment 56 Ernesto Manríquez 2010-05-07 07:19:13 EDT
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.
Comment 57 Peter Hutterer 2010-05-10 00:52:05 EDT
Moving to F-13.
Comment 58 Peter Hutterer 2010-05-10 18:12:18 EDT
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.
Comment 59 Ernesto Manríquez 2010-05-17 18:29:17 EDT
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.
Comment 60 Peter Hutterer 2010-05-17 18:57:37 EDT
thanks, closing as fixed then. Sorry about the delay, the patch fell under the table.