eGalax Touchscreen calibration problems

[Peter Hutterer]

On Mon, Apr 18, 2011 at 12:38:23PM -0400, Ken Emmons Jr. wrote:
> I am having issues calibrating and swapping axes on an eGalax
> touchscreen. Xorg does seem to recognize the device as an input device
> and seemingly tries to move the cursor appropriately to its wrong
> calibration. I had to pass usbhid.quirks=0xeef:0x1:0x40 to the kernel
> boot parameters to get the kernel HID driver to handle the touchscreen
> properly. Prior to this it did not work at all.
> 
> I see valid event interfaces and can in fact get events from them using
> the evtest.c program at a console. When I try to use evdev driver
> configured to an event interface (using xorg.conf) xorg logs state that
> evdev doesn't know what to do with the device. When I use the evtouch
> driver it just crashes. Most of the help online is using the evtouch
> driver and this really isn't doing me any good as a result. From what I
> can see and have read this driver is going away anyhow. 
> 
> It is probably worth noting that when I type xinput list I see no notice
> of the touchscreen, but that there is just a "configured mouse". I
> suspect that the HAL layer is somehow doing something with combining my
> regular mouse and my HID touchscreen and xorg is just interpreting that.
> If this is the case should I be doing my calibrations from the HAL, or
> is that just passing the data to the Xorg server anyhow? 
> 
> I am using Debian Lenny on a embedded PowerPC computer and I am having
> problems finding information since most of it is circa 2008-2009. At
> this point I cannot upgrade the distribution, although that may be a
> possibility in the future.  
> 
> Xorg version 1.4.2
> 
> Any ideas? I'd be happy to do any reading, but I am jumping back and
> forth between different projects reading conflicting information at this
> point. 

newer kernels and evdev versions shouldn't have any problems with the eGalax
screens. the kernel patch does pretty much what you passed to the boot
params.

Can't remember if evdev needed fixes for it but the general rule is that if
it doesn't work in your current version and you can't upgrade, you're stuck.
your only chance is to figure out why evdev can't use the device (usually
that's because a missing button on the device that evdev needs to recognise
it). then you can try to hack it up there and hardcode the button mappings.

HAL does nothing other than shouting "hey, here's a device for you" and
passing optional configuration options. anything more fancy than that is in
the driver.

Cheers,
  Peter