With evtouch dropping out from most of Linux distributions I've stumbled upon the fact that GeneralTouch touchscreens are unusable with evdev.  In short, evdev is not a replacement for evtouch in case of GeneralTouch touchscreens.

What's wrong:  On quick touches the cursor stays where it is and "click" event goes into that position, not the place where finger touches the touchscreen -- FAIL.  On touches combined with dragging cursor follows the finger as expected -- OK.

Tested with evdev 2.3.2, 2.4.0, 2.4.99(dev) -- everything is the same.

I've found the problem.  Take a look at evtest output (it's short):

# evtest /dev/input/event5 
Input driver version is 1.0.0
Input device ID: bus 0x3 vendor 0xdfc product 0x1 version 0x1
Input device name: "General Touch Co. Ltd.  GeneralTouch USB Touchscreen"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
    Event code 330 (Touch)
  Event type 3 (Absolute)
    Event code 0 (X)
      Value      0
      Min        0
      Max    32767
    Event code 1 (Y)
      Value      0
      Min        0
      Max    32767
Testing ... (interrupt to exit)
Event: time 1281116494.389821, type 3 (Absolute), code 0 (X), value 955
Event: time 1281116494.389831, type 3 (Absolute), code 1 (Y), value 955
Event: time 1281116494.389835, -------------- Report Sync ------------
Event: time 1281116494.397807, type 1 (Key), code 330 (Touch), value 1
Event: time 1281116494.397821, -------------- Report Sync ------------
Event: time 1281116494.461812, type 1 (Key), code 330 (Touch), value 0
Event: time 1281116494.461829, -------------- Report Sync ------------
Event: time 1281116498.181990, type 3 (Absolute), code 0 (X), value 437
Event: time 1281116498.181999, type 3 (Absolute), code 1 (Y), value 1067
Event: time 1281116498.182003, -------------- Report Sync ------------
Event: time 1281116498.189977, type 1 (Key), code 330 (Touch), value 1
Event: time 1281116498.189990, -------------- Report Sync ------------
Event: time 1281116498.253977, type 1 (Key), code 330 (Touch), value 0
Event: time 1281116498.253992, -------------- Report Sync ------------
Event: time 1281116499.918069, type 3 (Absolute), code 0 (X), value 819
Event: time 1281116499.918078, type 3 (Absolute), code 1 (Y), value 738
Event: time 1281116499.918083, -------------- Report Sync ------------
Event: time 1281116499.926058, type 1 (Key), code 330 (Touch), value 1
Event: time 1281116499.926071, -------------- Report Sync ------------
Event: time 1281116499.966053, type 3 (Absolute), code 0 (X), value 815
Event: time 1281116499.966062, type 3 (Absolute), code 1 (Y), value 745
Event: time 1281116499.966066, -------------- Report Sync ------------
Event: time 1281116499.990061, type 3 (Absolute), code 0 (X), value 807
Event: time 1281116499.990067, type 3 (Absolute), code 1 (Y), value 758
Event: time 1281116499.990071, -------------- Report Sync ------------
Event: time 1281116500.022062, type 3 (Absolute), code 0 (X), value 798
Event: time 1281116500.022071, type 3 (Absolute), code 1 (Y), value 776
Event: time 1281116500.022075, -------------- Report Sync ------------
Event: time 1281116500.094060, type 3 (Absolute), code 0 (X), value 763
Event: time 1281116500.094066, type 3 (Absolute), code 1 (Y), value 829
Event: time 1281116500.174080, -------------- Report Sync ------------
Event: time 1281116500.246064, type 1 (Key), code 330 (Touch), value 0
Event: time 1281116500.246078, -------------- Report Sync ------------

There are two quick touches and one touch+drag in the output of evtest above. It's a bit strange that quick touch is reported as two events separated with "Sync".  The first event is absolute positioning and the second one is a touch.  No other touchscreen behaves like that -- all of them have one event with ABS_X + ABS_Y + BTN_TOUCH combined and only one 'Sync' following.

That's produced by GeneralTouch on touch:

Event: time 1281116494.389821, type 3 (Absolute), code 0 (X), value 955
Event: time 1281116494.389831, type 3 (Absolute), code 1 (Y), value 955
Event: time 1281116494.389835, -------------- Report Sync ------------
Event: time 1281116494.397807, type 1 (Key), code 330 (Touch), value 1
Event: time 1281116494.397821, -------------- Report Sync ------------

That's produced upon release:

Event: time 1281116494.461812, type 1 (Key), code 330 (Touch), value 0
Event: time 1281116494.461829, -------------- Report Sync ------------

That's unusual for touchscreens to report touches that way, nevertheless it's not incorrect or illegal.  I've checked the data on the wire - yes, the hardware is working extactly like that.  Linux's kernel module (usbtouchscreen) works as expected -- it translates hardware events into software ones without extra mangling.  In other words the kernel properly supports GeneralTouch touchscreens, no bugs.

That's how that events converted into xinput events:

# xinput test 9
button press   1 
button release 1 
button press   1 
button release 1 
button press   1 
motion a[0]=5308 a[1]=7813 
motion a[0]=5843 a[1]=8296 
motion a[0]=6456 a[1]=8842 
motion a[0]=7170 a[1]=9453 
motion a[0]=7834 a[1]=9936 
button release 1 
button press   1 
button release 1 

Drag is here, touches are here, but no absolute positioning *before* touches.

Now let's look at evdev.c -- there is a function EvdevPostAbsoluteMotionEvents(). It pretty simple, big comment and the only one 'if' statement.  Looks like that:

void
EvdevPostAbsoluteMotionEvents(InputInfoPtr pInfo, int *num_v, int *first_v,
                              int v[MAX_VALUATORS])
{
    EvdevPtr pEvdev = pInfo->private;

    /*
     * Some devices only generate valid abs coords when BTN_DIGI is
     * pressed.  On wacom tablets, this means that the pen is in
     * proximity of the tablet.  After the pen is removed, BTN_DIGI is
     * released, and a (0, 0) absolute event is generated.  Checking
     * pEvdev->tool here, lets us ignore that event.  pEvdev->tool is
     * initialized to 1 so devices that don't use this scheme still
     * just work.
     */
    if (pEvdev->abs && pEvdev->tool) {
        xf86PostMotionEventP(pInfo->dev, TRUE, *first_v, *num_v, v);
    }
}

That "pEvdev-tool" check is the problem.  The comment above is wrong.  Yes, pEvdev-tool is initialized with 1. But it is set to 0 whenever EvdevProcessKeyEvent() is called with ev->code == BTN_TOUCH and ev->value == 0 (aka release).  And all the future pure absolute positioning events (not combined with touches) are ignored.

In perfect world that check should be removed at all.  It's better to fix hardware drivers for touchpads to not produce martian events that require some special handling, which, in turn, breaks support for some other hardware.

In imperfect world that's enough to replace that 'if' with something like that:

    if (pEvdev->abs && ((pEvdev->flags & EVDEV_TOUCHSCREEN) || pEvdev->tool)) {