Bug 473144

Created attachment 324782 [details]
Xorg.0.log

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.

Created attachment 327132 [details]
Output of evtest /dev/input/event7

Created attachment 327133 [details]
Output from lshal

Created attachment 327134 [details]
Output from cat /proc/bus/input/devices

I've attached the requested info.

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.

Created attachment 327343 [details]
lshal output from updated hal

Created attachment 327344 [details]
Xorg.0.log with updated hal

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)

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".

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

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

Created attachment 335095 [details]
Xorg.0.log from latest rawhide (March 13)

Created attachment 335096 [details]
dmesg from latest rawhide kernel

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/

(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.

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

(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?

As far as it fixes the problem that some touchscreens like mine
were not correctly recognized from the kernel - yes

Reporter? Any opinions on 2.6.29 kernel? Can you still reproduce the issue with the latest upgrades in Fedora/Rawhide?

I will retest as soon as I am able to update my system (https://bugzilla.redhat.com/show_bug.cgi?id=473142)

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.

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.

(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.

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

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.

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.

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

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?

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?

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!

except if explicity configured, the X server doesn't listen to /dev/input/mice or mouseX, so that's unlikely the problem.

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.

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

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!

is there any chance of seeing that fdi file?

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

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

I guess the location /var/lib/eeti.param ist "hard-coded"
and cannot be changed.
The rest looks good IMHO

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.

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>

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;

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.

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>

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.

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

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!

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

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.

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.

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.

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.

It's working!!  I switched over to Ubuntu Lucid Lynx!

https://patchwork.kernel.org/patch/76210/

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.

Moving to F-13.

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.

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.

thanks, closing as fixed then. Sorry about the delay, the patch fell under the table.