eGalax touchscreen configured as tablet

Bug #549447 reported by Benjamin Meeusen
182
This bug affects 32 people
Affects Status Importance Assigned to Milestone
xserver-xorg-input-evdev (Fedora)
Fix Released
Medium
xserver-xorg-input-evdev (Ubuntu)
Fix Released
Low
Unassigned
Declined for Lucid by Brian Murray
Declined for Maverick by Brian Murray

Bug Description

Binary package hint: xserver-xorg-input-evdev

from Xorg.0.log: (II) "eGalax Inc. Touch": Configuring as tablet
The touchscreen is a 7" resistive vga monitor.

Every touch makes the cursor move to the upper left corner and register the click there.
My calibration values, coming from an ubuntu 8.10 installation using evtouch, are loaded through a udev rule. Changing them or using no values at all for calibration does not change anything.

If I install the eGalax driver (http://home.eeti.com.tw/web20/eGalaxTouchDriver/linuxDriver.htm), the device is listed twice in "xinput list" and if I disable the device using evdev, I can calibrate the screen using the eGalax tool and everythings works. If I don't disable the device using evdev, everything works too, except that every touch is preceded by a touch to the upper left corner.
But I'd rather get it working using only evdev.

ProblemType: Bug
Architecture: i386
Date: Sat Mar 27 11:07:38 2010
DistroRelease: Ubuntu 10.04
DkmsStatus: Error: [Errno 2] No such file or directory
InstallationMedia: Ubuntu-Netbook 10.04 "Lucid Lynx" - Beta i386 (20100318)
Package: xserver-xorg-input-evdev 1:2.3.2-3ubuntu2
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-17-generic root=UUID=a1d7d9b3-1a8f-4e55-b622-ec5497d7797c ro quiet splash
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-17.26-generic 2.6.32.10+drm33.1
SourcePackage: xserver-xorg-input-evdev
Uname: Linux 2.6.32-17-generic i686
dmi.bios.date: 04/03/2009
dmi.bios.vendor: Intel Corp.
dmi.bios.version: LF94510J.86A.0171.2009.0403.0118
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: D945GCLF2
dmi.board.vendor: Intel Corporation
dmi.board.version: AAE46416-106
dmi.chassis.type: 3
dmi.modalias: dmi:bvnIntelCorp.:bvrLF94510J.86A.0171.2009.0403.0118:bd04/03/2009:svn:pn:pvr:rvnIntelCorporation:rnD945GCLF2:rvrAAE46416-106:cvn:ct3:cvr:
glxinfo: Error: [Errno 2] No such file or directory
system:
 distro: Ubuntu
 codename: lucid
 architecture: i686
 kernel: 2.6.32-17-generic

Revision history for this message
In , Matěj (matj-redhat-bugs) wrote :

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

Revision history for this message
In , Jurgen (jurgen-redhat-bugs) wrote :

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

Revision history for this message
In , Jurgen (jurgen-redhat-bugs) 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.

Revision history for this message
In , Max (max-redhat-bugs) 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.

Revision history for this message
In , Peter (peter-redhat-bugs) 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.

Revision history for this message
In , Max (max-redhat-bugs) 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

Revision history for this message
In , Peter (peter-redhat-bugs) 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.

Revision history for this message
In , jordan (jordan-redhat-bugs) 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.

Revision history for this message
In , Bug (bug-redhat-bugs) 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

Revision history for this message
In , Matt (matt-redhat-bugs) 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?

Revision history for this message
In , Max (max-redhat-bugs) 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?

Revision history for this message
In , Matt (matt-redhat-bugs) 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!

Revision history for this message
In , Peter (peter-redhat-bugs) wrote :

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

Revision history for this message
In , Matt (matt-redhat-bugs) 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.

Revision history for this message
In , Max (max-redhat-bugs) 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

Revision history for this message
In , Ritchey (ritchey-redhat-bugs) 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!

Revision history for this message
In , Julian (julian-redhat-bugs) wrote :

is there any chance of seeing that fdi file?

Revision history for this message
In , Max (max-redhat-bugs) 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

Revision history for this message
In , Matt (matt-redhat-bugs) 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

Revision history for this message
In , Max (max-redhat-bugs) wrote :

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

Revision history for this message
In , Guy (guy-redhat-bugs) 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.

Revision history for this message
In , Chris (chris-redhat-bugs) 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>

Revision history for this message
In , Chris (chris-redhat-bugs) 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;

Revision history for this message
In , Peter (peter-redhat-bugs) 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.

Revision history for this message
In , Chris (chris-redhat-bugs) 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>

Revision history for this message
In , Chris (chris-redhat-bugs) 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.

124 comments hidden view all 140 comments
Revision history for this message
Benjamin Meeusen (ravenous) wrote :
Revision history for this message
Benjamin Meeusen (ravenous) wrote :

The above happened while the usbtouchscreen module was blacklisted (this was needed for the eGalax module). If I let the usbtouchscreen module load, the touchscreen is configured as a touchscreen.
But 'xinput list-props' shows only two axis labels (Abs X and Abs Y), and only part of the touches are registered. 'xinput test' shows very little output (a simple movement shows a couple of lines) while touching all over the screen, e.g. it shows 'button press', then I touch the screen a lot, it shows some 'motion...' output, and then after some touching it shows 'button release'.

If I then do 'rmmod usbtouchscreen' and plug the touchscreen (usb) out and back in, the touchscreen is configured as tablet and all touches make the cursor go to the upper left corner. It is also showing 4 axis labels (Abs X, Y, Z and Rotary X). 'xinput test' shows considerably more output than before (where a simple movement now shows 100 lines)

If I then load the usbtouchscreen module again (modprobe usbtouchscreen) and plug the touchscreen out and in, it stays registered as tablet (also after X restart, should that matter).

124 comments hidden view all 140 comments
Revision history for this message
In , Bug (bug-redhat-bugs) 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

123 comments hidden view all 140 comments
Revision history for this message
cmd_ (cemede) wrote :

With a ubuntu 9.10 fresh install + eGalax driver ( 3.00.3719 or 3.01.4001 beta from the eGalax website) works well!

But with a ubuntu 10.04 rc + eGalax driver or evtouch, appear the problem commented by Benjamin, "Every touch makes the cursor move to the upper left corner and register the click there."

With 10.04 rc, setup.sh from the eGalax driver needs a few modifications to proper install:
-blacklist file points to /etc/modprobe.d/blacklist, -> change to /etc/modprobe.d/blacklist.conf
-install script fail if xorg.conf file doesn't exist, -> create file
-install script also fail if ServerLayout section in xorg.conf isn't present, -> add section

Anyway this latest problems from setup.sh script isn't a bug from ubuntu package.

Changed in xserver-xorg-input-evdev (Ubuntu):
status: New → Confirmed
Revision history for this message
John Ross (johnross-johnross) wrote :

I also ran into this bug when upgrading from 9.10 to 10.04 RC on an Asus 901 modified with touchscreen that uses eGalax driver. Everything worked great prior to upgrade but I got the same "jump to upper left corner" type of behavior no matter what version of eGalax driver I used. I've reverted to 9.10 until the issue is resolved.

Revision history for this message
Maximka (maxim-kraev-gmail) wrote :

Executing "xinput set-int-prop "eGalax Inc. USB TouchController" 183 8 0" solved problem for me. I have script which automatically execute command on X started.

Revision history for this message
UOneChancellor (random-system) wrote :

I have ubuntu 10.04 and msi u100 with touchscreen

Bus 001 Device 004: ID 0eef:0001 D-WAV Scientific Co., Ltd eGalax TouchScreen
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB

with original driver eGalax driver ( 3.00.3719 or 3.01.4001 beta from the eGalax website) i can calibrate it.

But with driver of ubuntu 10.04, the touchscreen work, but THERE IS NOT the tool for calibrate....

can you help me?

bye
Lele

Revision history for this message
chops (chopssmith-media) wrote :

This is affecting me too (on an HP tx1000 series, new install of Lucid on a new HDD). I have no real idea about these things, but am wondering if it is some kind of configuration which needs to be written. For instance if whatever tells it how to work thinks that the screen is 0 x 0 pixels because it has not been told otherwise. That, presumably would send it to the top left hand corner?

I think this adds weight to the need for a calibration programme, like there was in an earlier version of Ubuntu (Gutsy?).

If one of you clever people can come up with a little how-to for the thick but brave (or stupid!) like me, that would be awesome!

Thanks, and keep up the good work!

Rich

Revision history for this message
cmd_ (cemede) wrote :

Yes, without doubt, we need an application WITH GUI (like the eGalax solution) to calibrate all touchscreens covered by evdev driver.
I see a lot of people that made a little app for doing this, but none of them are in the ubuntu repositories.

Check this blueprints:
https://blueprints.launchpad.net/ubuntu/+spec/mobile-general-resolution-for-touchscreen-handling
and the detailed version here:
https://wiki.ubuntu.com/JauntyTouchscreenHandling

In this last link you can notice a gui app to setup a touchscreen, not only calibration tool, also precision, swap axes, timeouts.. why this app isn't in actual ubuntu releases (and repositories)?

Revision history for this message
Ernesto Manriquez (alejandronova) wrote :

The question isn't why that app isn't in Ubuntu repositories, because chances are that app was never made, and vapourware naturally doesn't exist in any repo. My question is another. Why this program isn't in Ubuntu repos?

http://www.freedesktop.org/wiki/Software/xinput_calibrator

That is a generic XInput calibrator. Works like a charm with evtouch, and can write UDEV rules (perfect for Lucid). Please, check this: https://bugzilla.redhat.com/show_bug.cgi?id=473144 . With that info and the HAL rule there, my eGalax touchscreen works in Fedora 12 (with HAL). Can you work a little with that HAL rule, turn it into an UDEV rule, and make my touchscreen work?

Revision history for this message
Ernesto Manriquez (alejandronova) wrote :

Meh: s/evtouch/evdev/g ...

117 comments hidden view all 140 comments
Revision history for this message
In , Ernesto (ernesto-redhat-bugs) 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!

Revision history for this message
In , Ernesto (ernesto-redhat-bugs) 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://<email address hidden>/msg09730.html

Revision history for this message
In , Ernesto (ernesto-redhat-bugs) 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.

Revision history for this message
In , Ernesto (ernesto-redhat-bugs) 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.

Revision history for this message
In , Chris (chris-redhat-bugs) 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.

Revision history for this message
In , Ernesto (ernesto-redhat-bugs) 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.

121 comments hidden view all 140 comments
Revision history for this message
Ernesto Manriquez (alejandronova) wrote :

More on this.

I'm now with Fedora 13 (using a very Lucid-like system) and the behaviour was exactly as described in this bug. Booting with the 2.6.32 kernel provided by Fedora 12 makes my touchscreen work properly, but it gets detected as two devices instead of one. The problem is narrowed to a Fedora 12 only patch for 2.6.32, that introduced HID_QUIRK_MULTI_INPUT for eGalax touchscreens in drivers/hid/usbhid/hid-quirks.c. We are demanding the return of that patch to Fedora 13, to divide the touchscreen in 2 device, but conquer the touchscreening here. If we can get X to recognize the touchscreen as a tablet, or as a whatever that gives reliable X and Y coordinates, and answer to touch, we are done.

Keep an eye on this, Ubuntu followers! The source of this issue is this. It is not evdev, it's the kernel. And that patch is the solution. I'll report my advances getting this fixed under Fedora 13.

122 comments hidden view all 140 comments
Revision history for this message
In , Ritchey (ritchey-redhat-bugs) wrote :

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

Revision history for this message
In , Ernesto (ernesto-redhat-bugs) wrote :
Revision history for this message
In , Ernesto (ernesto-redhat-bugs) 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.

123 comments hidden view all 140 comments
Revision history for this message
kb1605 (kb1605-deactivatedaccount) wrote :

Hello everyone,
i have found a solution that at least works for me, but I am m pretty sure that it will also work for most of you guys.I Use Ubuntu 10.04 and have an eGalaxy USB-Touchpannel(Driver: eGalaxTouch-3.00.3719)

Of course the first step was to install the eGalaxy drivers as mentioned by "cmd_", quote:
"With 10.04 rc, setup.sh from the eGalax driver needs a few modifications to proper install:
-blacklist file points to /etc/modprobe.d/blacklist, -> change to /etc/modprobe.d/blacklist.conf
-install script fail if xorg.conf file doesn't exist, -> create file
-install script also fail if ServerLayout section in xorg.conf isn't present, -> add section"

Maximka's way of fixing the problem is right.Here is what I have done, step by step:
sya@7up:~$ xinput -list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ ETPS/2 Elantech Touchpad id=15 [slave pointer (2)]
⎜ ↳ Macintosh mouse button emulation id=16 [slave pointer (2)]
⎜ ↳ egalax id=6 [slave pointer (2)]
⎜ ↳ eGalax Inc. Touch id=11 [slave pointer (2)]
As you can see "xinput-list" showas two egalaxy devices,
by using the command: <xinput -test "egalax"> and <xinput -test "eGalax Inc. Touch"> I recognized that the false click to the upper left corner is done by the device with the name "eGalax Inc. Touch".

So the next step is to deactivate this device, by taking a look at the device properties with the command:
 <xinput -list-props "eGalax Inc. Touch"> and afterwards deactivating the device with the command:
 <xinput -set-prop "eGalax Inc. Touch" "Device Enabled" 0 >.

Now the mousepointer moves correctly and there are no false clicks to the upper left corner.
In my case I also had to start the eGalaxyTouch configuation program and change the "mouse mode" to "click on touch".

bye
kb1605

Revision history for this message
Manolis Kapernaros (kapcom01) wrote :

The workaround that kb1605 suggested works fine for me.
But if there was a calibration app into ubuntu repos would be much better.
I tried using xinput_calibrator that Ernesto Manriquez suggested but i didnt managed to compile it.. i didnt tried it enough though..

123 comments hidden view all 140 comments
Revision history for this message
In , Peter (peter-redhat-bugs) wrote :

Moving to F-13.

Revision history for this message
In , Peter (peter-redhat-bugs) 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.

Revision history for this message
In , Ernesto (ernesto-redhat-bugs) 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.

Revision history for this message
In , Peter (peter-redhat-bugs) wrote :

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

125 comments hidden view all 140 comments
Revision history for this message
Ernesto Manriquez (alejandronova) wrote :

You haven't followed my advances in the Fedora bug lately.

Instead of surrendering to the blob, try appending this to the kernel line in /etc/grub.conf:

usbhid.quirks=0xeef:0x1:0x40

If you can't compile xinput_touchscreen, install this first and see what happens:

sudo apt-get install build-essential libgtkmm-dev

Revision history for this message
Ernesto Manriquez (alejandronova) wrote :

sudo apt-get install build-essential libgtkmm-2.4-dev

(sorry)

Revision history for this message
John Ross (johnross-johnross) wrote :

I tried kb1605 workaround. It only works with "click on touch" mode. This is fine for opening programs, tapping menus but useless if you intend to use the stylus to draw or write on the screen with something like xournal.

I have yet to try Ernesto's suggestions. More later...

Revision history for this message
chops (chopssmith-media) wrote :

It is good to see you guys still working on this. I installed the eGalax tool, and it worked ok (upside-down), but seemed to have some kind of conflict with the evdev driver (evdev seemed to take preference over eGalax when it was not disabled.)

I did the xinput -test on each device, and noticed that both output the co-ordinates, so my earlier suggestion of it not recognising the screen size was complete rubbish! You all probably had got there way before me, but I thought I would add it in case someone who did not know started frantically to 'fix' this issue, which is not an issue at all!

This all suggests to me that it should be something relatively simple- after all, evdev is registering the co-ordinates and the clicks, but not quite putting them together. I can't help feeling we (ok, you!) are nearly there, so keep up the good work, and thanks!

Revision history for this message
cmd_ (cemede) wrote :

Hi, now I have a working 10.04 + evdev driver, there are a few problems but works.

I started with a fresh ubuntu lucid install and:

- I added usbhid.quirks=0xeef:0x1:0x40 to /etc/default/grub, change line:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
to
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash usbhid.quirks=0xeef:0x1:0x40"

- Blacklisted usbtouchscreen module, add:

blacklist usbtouchscreen
to
/etc/modprobe.d/blacklist.conf

- Next I installed all neccesary deps to proper compile xinput calibrator (download here: http://github.com/tias/xinput_calibrator/downloads ):

$ sudo apt-get install build-essential libgtkmm-2.4-dev autoconf libtool

- After extract xinput files from the tgz/zip, enter to the decompressed directory and type:

$ ./autogen.sh
$ ./configure
$ make
$ sudo make install (optional, binary files are into ../src/ dir )

Here starts my problem, I want to calibrate the device but there are 2 listed into xinput list. After finding the right one with xinput test "id" I can get the correct values for the calibration, but I can only apply with this:

$ xinput set-int-prop "id from the right device" "Evdev Axes Swap" 8 1 #<-You probably doesn't need to do this
$ xinput set-int-prop "id from the right device" "Evdev Axis Calibration" 32 315 3902 337 3842

The id's changes every boot, and I can't apply the same configuration.

Also I tried adding the udev rules, but do not worked for me. Ernesto, you have luck with udev rules? lucid comes with evdev 2.3.2, this version supports udev rules?

Thanks.

Revision history for this message
Ernesto Manriquez (alejandronova) wrote :

I'm having the same problems as you, cmd_, but I rely heavily in workarounds.

I nailed in my KDE Autostart two desktop files, running this.

xinput set-int-prop 11 "Evdev Axis Calibration" 32 45 4008 121 3978
xinput set-int-prop 12 "Evdev Axis Calibration" 32 45 4008 121 3978

So, I simply assure myself that both eGalax devices (the true one and the fake one) are calibrated. One feature of xinput values is that you can set bogus values for a device that doesn't support them, so I use it.

The place to have these settings is not udev rules; is this:

/usr/share/X11/xorg.conf.d/10-evdev.conf

Copy that file to /etc/X11/xorg.conf.d

Fedora 13 and Lucid share their configuration mechanism: a pure UDEV mechanism. The technique is easier than you think.

Add to that file these lines and see what happens.

    MatchProduct "eGalax"
    Option "Calibration" "45 4008 121 3978" <--or your calibration data

Revision history for this message
cmd_ (cemede) wrote :
Download full text (3.4 KiB)

Okay, I found the way to manage xorg.conf config under lucid.
Lucid doesn't have /usr/share/X11/xorg.conf.d/ or /etc/X11/xorg.conf.d/, the correct directory is /usr/lib/X11/xorg.conf.d/.

Inside this directory resides 05-evdev.conf file with evdev driver properties/configuration.

I just edited /usr/lib/X11/xorg.conf.d/05-evdev.conf adding this section:

Section "InputClass"
        Identifier "eGalax"
        MatchProduct "eGalax"
        MatchDevicePath "/dev/input/event*"
        Driver "evdev"
        Option "SwapAxes" "on" #<- This is optional!
        Option "Calibration" "415 3906 406 3862"
EndSection

I rebooted and voilá, it worked! :D

Now let's take a look on /var/log/Xorg.0.log

...
(II) config/udev: Adding input device eGalax Inc. USB TouchController (/dev/input/event3)
(**) eGalax Inc. USB TouchController: Applying InputClass "evdev pointer catchall"
(**) eGalax Inc. USB TouchController: Applying InputClass "eGalax"
(**) eGalax Inc. USB TouchController: always reports core events
(**) eGalax Inc. USB TouchController: Device: "/dev/input/event3"
(**) Option "SwapAxes" "on"
(II) eGalax Inc. USB TouchController: Found 3 mouse buttons
(II) eGalax Inc. USB TouchController: Found absolute axes
(II) eGalax Inc. USB TouchController: Found x and y absolute axes
(II) eGalax Inc. USB TouchController: Configuring as mouse
(**) eGalax Inc. USB TouchController: YAxisMapping: buttons 4 and 5
(**) eGalax Inc. USB TouchController: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(II) XINPUT: Adding extended input device "eGalax Inc. USB TouchController" (type: MOUSE)
(II) eGalax Inc. USB TouchController: initialized for absolute axes.
(II) config/udev: Adding input device eGalax Inc. USB TouchController (/dev/input/js0)
(II) No input driver/identifier specified (ignoring)
(II) config/udev: Adding input device eGalax Inc. USB TouchController (/dev/input/mouse1)
(II) No input driver/identifier specified (ignoring)
...
...
(II) config/udev: Adding input device eGalax Inc. USB TouchController (/dev/input/event4)
(**) eGalax Inc. USB TouchController: Applying InputClass "evdev tablet catchall"
(**) eGalax Inc. USB TouchController: Applying InputClass "eGalax"
(**) eGalax Inc. USB TouchController: always reports core events
(**) eGalax Inc. USB TouchController: Device: "/dev/input/event4"
(**) Option "SwapAxes" "on"
(II) eGalax Inc. USB TouchController: Found absolute axes
(II) eGalax Inc. USB TouchController: Found x and y absolute axes
(II) eGalax Inc. USB TouchController: Found absolute tablet.
(II) eGalax Inc. USB TouchController: Configuring as tablet
(**) eGalax Inc. USB TouchController: YAxisMapping: buttons 4 and 5
(**) eGalax Inc. USB TouchController: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(II) XINPUT: Adding extended input device "eGalax Inc. USB TouchController" (type: TABLET)
(II) eGalax Inc. USB TouchController: initialized for absolute axes.
(II) config/udev: Adding input device eGalax Inc. USB TouchController (/dev/input/mouse2)
(II) No input driver/identifier specified (ignoring)

You can notice the "eGalax" InputClass is applied, appearing Option "SwapAxes" "on", the...

Read more...

Revision history for this message
chops (chopssmith-media) wrote :

OK. I am very excited! I followed cmd_'s post #18, with the calibration information put into '/usr/lib/X11/xorg.conf.d/05-evdev.conf', as in post #20. guess what? It works beautifully! I think it is the best I have ever had it working, in the 2 years (4 Ubuntu versions), and on any OS.

 Now to get it into the default config., and the calibrator (or something similar/ even better) into the repos. The most exciting thing, to my mind, is that I won't have to go through the whole lot again for every kernel upgrade, as has been the case in the past.

I am guessing by the log output in #20 that there are some hidden issues, about which I have no knowledge, and little concern, if I am honest, because it works, but I have to say...

Well done, guys, and thanks!

Revision history for this message
Erik de Castro Lopo (erikd) wrote :

I had this touchscreen working correctly in karmic and after an upgrade to lucid its broken.

Revision history for this message
Erik de Castro Lopo (erikd) wrote :

Tried the recipe from #18 and #20 and I still don't have a working touch screen.

Revision history for this message
cmd_ (cemede) wrote :

Hi Erik, not all eGalax controllers are HID compatible devices and needs a special driver ("touchscreen" module) instead of evdev. But apparently some HID-compatible and non-HID have same usbid's and it's difficult to identify what device is.
The easy way to fix this it's simple, try both 2 modules, not at same time.

Anyway, you upgraded from a previous version or with a fresh installation? you have problem with some step in concrete? can you post your Xorg log?

Revision history for this message
Erik de Castro Lopo (erikd) wrote : Re: [Bug 549447] Re: eGalax touchscreen configured as tablet

cmd_ wrote:

> Hi Erik, not all eGalax controllers are HID compatible devices

But my device has the exact same USB id as the one in this bug:

    Bus 005 Device 002: ID 0eef:0001 D-WAV Scientific Co., Ltd eGalax TouchScreen

> Anyway, you upgraded from a previous version or with a fresh
> installation?

No, I upgraded via do-release-upgrade from karmic where the touchscreen
was working.

> you have problem with some step in concrete?

The steps are clear enough, they just didn't work :-).

> can you post your Xorg log?

I will attach it to the bug.

1 comments hidden view all 140 comments
Revision history for this message
Erik de Castro Lopo (erikd) wrote :

Got it working.

The problem was that although grub2 was installed, grub1 was what was actually being used.

Revision history for this message
cmd_ (cemede) wrote :

Good for you Erik, you're fast xD sorry for answering so late.

In your Xorg.0.log doesn't appear 2 eGalax devices (tablet and pointer), this is because "usbquirks" isn't being applied. You correctly find what causes this problem, only grub2 uses /etc/default/grub or /etc/grub.d/* files ( https://wiki.ubuntu.com/Grub2#Grub%202%20Files%20&%20Folders ).

Remember, this is only a temporal fix, the bug still alive.

Revision history for this message
tsm124 (tsm1248) wrote :

Ok the issue so far is just disabling that extra device in my case

sudo xinput -set-prop "eGalax Inc. USB TouchController" "Device Enabled" 0

this command sets the device off but how do i set it off for everyboot it re-enables itself each boot + to add to this conflict when the keyboard or mouse un plugged ubuntu restarts....huh

Any fixes for anyone?

Revision history for this message
kb1605 (kb1605-deactivatedaccount) wrote :

@tsm124
The easy way ist to:
Open: Menu -> System -> Preferences -> Startup Applications
then click on Add... and insert your code: sudo xinput -set-prop "eGalax Inc. USB TouchController" "Device Enabled" 0

Next time use google for such a basic question ;-)

I also still dont have a fix for the x-server-restart when plugging in a mouse or opening the mouse settings.
Disabeling the second divice is still just kind of a workaround and no final solution or fix.
It seems like its better to 'fix' the problem like "Ernesto Manriquez" and "cmd" did (with my workaround you have the problem that you can only do click on touch).

P.S.: for everyone who is searching for a good calibration program I can recommend the calibration program comming with the eGalax driver. Its the best calibration tool I have seen till now, including 25Points Calibration and edge compensation....

Revision history for this message
Ernesto Manriquez (alejandronova) wrote :

This bug was fixed on Fedora, kernel patch! Watch this!

Revision history for this message
Ernesto Manriquez (alejandronova) wrote :

buurin from FedoraForum posted an alternative way to introduce the missing quirks: nail this in your /etc/modprobe.d/local.conf.

options usbhid quirks=0x0eef:0x0001:0x0040

The effect is the same.

BTW, do the eGalax calibration utility work with evdev? I'd be very (positively) surprised if it worked ;).

Revision history for this message
Ernesto Manriquez (alejandronova) wrote :

Finishing my round of spam, according to this: https://patchwork.kernel.org/patch/76210/ this bug should be ancient history with Maverick Meerkat. If I remove all the quirks workarounds, and simply install the Maverick backported kernel from ppa:kernel-ppa/ppa , touchscreen will work OOTB, with only the configuration posted by cmd_ remaining. Can anybody confirm my thoughts?

Revision history for this message
Benjamin Meeusen (ravenous) wrote :
Download full text (3.5 KiB)

I used the livecd Maverick Alpha 3 Netbook. Without the usbhid.quirks
option, the cursor stays in the upper left corner. With the
usbhid.quirks option, I can use xinput_calibrator, set the 'Evdev Axes
Swap' and the 'Evdev Axis Inversion' to 1 and have a working
touchscreen.
Now I've installed the backported kernel (same kernel as in Alpha 3, I
believe) on my existing installation, without any custom boot options
and the cursor still goes to the upper left corner.

On 8 August 2010 00:28, Ernesto Manriquez <email address hidden> wrote:
> Finishing my round of spam, according to this:
> https://patchwork.kernel.org/patch/76210/ this bug should be ancient
> history with Maverick Meerkat. If I remove all the quirks workarounds,
> and simply install the Maverick backported kernel from ppa:kernel-
> ppa/ppa , touchscreen will work OOTB, with only the configuration posted
> by cmd_ remaining. Can anybody confirm my thoughts?
>
> --
> eGalax touchscreen configured as tablet
> https://bugs.launchpad.net/bugs/549447
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “xserver-xorg-input-evdev” package in Ubuntu: Confirmed
> Status in “xserver-xorg-input-evdev” package in Fedora: Unknown
>
> Bug description:
> Binary package hint: xserver-xorg-input-evdev
>
> from Xorg.0.log: (II) "eGalax Inc. Touch": Configuring as tablet
> The touchscreen is a 7" resistive vga monitor.
>
> Every touch makes the cursor move to the upper left corner and register the click there.
> My calibration values, coming from an ubuntu  8.10 installation using evtouch, are loaded through a udev rule. Changing them or using no values at all for calibration does not change anything.
>
> If I install the eGalax driver (http://home.eeti.com.tw/web20/eGalaxTouchDriver/linuxDriver.htm), the device is listed twice in "xinput list" and if I disable the device using evdev, I can calibrate the screen using the eGalax tool and everythings works. If I don't disable the device using evdev, everything works too, except that every touch is preceded by a touch to the upper left corner.
> But I'd rather get it working using only evdev.
>
> ProblemType: Bug
> Architecture: i386
> Date: Sat Mar 27 11:07:38 2010
> DistroRelease: Ubuntu 10.04
> DkmsStatus: Error: [Errno 2] No such file or directory
> InstallationMedia: Ubuntu-Netbook 10.04 "Lucid Lynx" - Beta i386 (20100318)
> Package: xserver-xorg-input-evdev 1:2.3.2-3ubuntu2
> ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-17-generic root=UUID=a1d7d9b3-1a8f-4e55-b622-ec5497d7797c ro quiet splash
> ProcEnviron:
>  LANG=en_US.utf8
>  SHELL=/bin/bash
> ProcVersionSignature: Ubuntu 2.6.32-17.26-generic 2.6.32.10+drm33.1
> SourcePackage: xserver-xorg-input-evdev
> Uname: Linux 2.6.32-17-generic i686
> dmi.bios.date: 04/03/2009
> dmi.bios.vendor: Intel Corp.
> dmi.bios.version: LF94510J.86A.0171.2009.0403.0118
> dmi.board.asset.tag: Base Board Asset Tag
> dmi.board.name: D945GCLF2
> dmi.board.vendor: Intel Corporation
> dmi.board.version: AAE46416-106
> dmi.chassis.type: 3
> dmi.modalias: dmi:bvnIntelCorp.:bvrLF94510J.86A.0171.2009.0403.0118:bd04/03/2009:svn:pn:pvr:rvnIntelCorporation:rnD945GCLF2:rvrAAE4...

Read more...

Revision history for this message
Benjamin Meeusen (ravenous) wrote :

With the quirks option, xorg detects two devices for my touchscreen, one TABLET and one MOUSE, both with the same name. Is this normal behaviour? It makes assigning the right ID to 'xinput set-int-prop' a bit harder, since the ID changes if you plug other usb devices or plug it into another usb port.

Revision history for this message
Benjamin Meeusen (ravenous) wrote :

I've read the thread again and found the solution using xorg.conf.d

Section "InputClass"
        Identifier "eGalax calibration"
        MatchProduct "eGalax Inc. Touch"
        Option "Calibration" "2004 66 76 1942"
        Option "SwapAxes" "1"
        Option "InvertX" "1"
        Option "InvertY" "1"
EndSection

I was trying to do this using udev rules, but then I came across https://wiki.kubuntu.org/X/InputConfiguration
which says: "Note: The x11_options properties are not supported in Ubuntu 10.04. Use xorg.conf.d snippets instead."

Revision history for this message
Ernesto Manriquez (alejandronova) wrote :

@Benjamin. This is normal behaviour for the quirks option. One of those devices is mute, the other one works.

Revision history for this message
MacRules (macrules) wrote :

Hi all,

I am not sure if this is the proper place, but I'll just try and hope nobody is pissed or anyone points me in the right direction.
I have a touchscreen branded GeneralTouch with id 0dfc:0001 .
It seems to get only partly loaded, because I just get no screen input.
This is my Xorg log:
(II) config/udev: Adding input device Sensing Win7-TwoFinger (/dev/input/event5)
(**) Sensing Win7-TwoFinger: Applying InputClass "evdev touchscreen catchall"
(**) Sensing Win7-TwoFinger: always reports core events
(**) Sensing Win7-TwoFinger: Device: "/dev/input/event5"
(II) Sensing Win7-TwoFinger: Found absolute axes
(II) Sensing Win7-TwoFinger: Found x and y absolute axes
(II) Sensing Win7-TwoFinger: Found absolute touchscreen
(II) Sensing Win7-TwoFinger: Configuring as touchscreen
(**) Sensing Win7-TwoFinger: YAxisMapping: buttons 4 and 5
(**) Sensing Win7-TwoFinger: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(II) XINPUT: Adding extended input device "Sensing Win7-TwoFinger" (type: TOUCHSCREEN)
(II) Sensing Win7-TwoFinger: initialized for absolute axes.
(II) config/udev: Adding input device Sensing Win7-TwoFinger (/dev/input/mouse1)
(II) No input driver/identifier specified (ignoring)

I also would like to point you all to the xinput_calibrator deb (also source en Fedora rpm):
http://github.com/tias/xinput_calibrator/downloads

When I run that, no input is registered from touching the screen, but my mouse clicks from external mouse are.

Does anyone know what I can do to get it working?
I was thinking about the usb quircks, but I do not know what 0040 means, so I do not know how to get the whole string for my device.

Any help is greatly appreciated!

Revision history for this message
MacRules (macrules) wrote :

And the kernel output:
mypad@mypad-laptop:/usr/lib/X11/xorg.conf.d$ dmesg | grep touch
[ 5.915284] usbcore: registered new interface driver usbtouchscreen

Revision history for this message
cmd_ (cemede) wrote :

Hi MacRules, thanks to point to xinput_calibrator .deb package (at last!).

For first, you have a touch-screen from a different vendor, GeneralTouch, not eGalax, this vendor make its own controllers? perhaps take one from another vendor and remark/rename (this is correct term?) it as theirs. Anyway, try drivers from your vendor: http://www.generaltouch.com/zmp/Driver.htm
This: http://www.generaltouch.com/zmp/gtusbdriver4ubuntuv1.1d2beta.tgz (vendor says "Applicable For 32bit FC 8/9/12, ubuntu 8.04/8.10/9.04/9.10"

But If you want to make this to work with evdev driver, let's try this:
-test the device with: xinput -test "device id" and touch the screen, you see something? (to see device id use xinput -list)
-if you are using evdev driver, blacklist usbtouchscreen driver, write "blacklist usbtouchscreen" line to /etc/modprobe.d/blacklist.conf

Changed in utouch:
status: New → Invalid
affects: xserver-xorg-input-evdev (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged
description: updated
Changed in linux (Ubuntu Natty):
status: Triaged → Incomplete
tags: added: kernel-key
Changed in linux (Ubuntu Natty):
milestone: none → natty-updates
Changed in linux (Ubuntu):
status: Incomplete → Triaged
Changed in linux (Ubuntu Natty):
assignee: nobody → Jaroslaw Filiochowski (jarfil)
affects: linux (Ubuntu Natty) → xserver-xorg-input-evdev (Ubuntu Natty)
Changed in xserver-xorg-input-evdev (Ubuntu Natty):
status: Incomplete → In Progress
tags: added: patch
penalvch (penalvch)
no longer affects: xserver-xorg-input-evdev (Ubuntu Natty)
no longer affects: xserver-xorg-input-evdev (Ubuntu)
affects: oif → xserver-xorg-input-evdev (Ubuntu)
Changed in xserver-xorg-input-evdev (Ubuntu):
status: Invalid → Incomplete
importance: Undecided → Low
Søren Holm (sgh)
Changed in xserver-xorg-input-evdev (Ubuntu):
status: Incomplete → Fix Released
Changed in xserver-xorg-input-evdev (Fedora):
importance: Unknown → Medium
status: Unknown → Fix Released
Displaying first 40 and last 40 comments. View all 140 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.