> > 1.1.0 is still the latest upstream release, but 3 big patches have been > committed upstream since then (see > http://gitweb.freedesktop.org/?p=xorg/driver/xf86-input-fpit.git). > PROXIMITY is still set to 0x20, but the code has moved/changed. So it > would be good to test it before complaining to upstream about your bug. > Is there a chance you try building the upstream git repository? >
about the latest relese (named "update from J Blanchard part 3" . at first it didn't compile. I replaced ----- *x = xf86ScaleAxis(v0, 0, priv->screen_width, axes[0].min_value, axes[0].max_value); *y = xf86ScaleAxis(v1, 0, priv->screen_height, axes[1].min_value, axes[1].max_value); ---- by ---- *x = xf86ScaleAxis(v0, 0, priv->screen_width, priv->fpitMinX, priv->fpitMaxX); *y = xf86ScaleAxis(v1, 0, priv->screen_height, priv->fpitMinY, priv->fpitMaxY); ---- it may break the screen rotation feature introduced by Justin in this release. Here is the behavior : the cursor wanders erratically on the screen whenever I approach the pen. about 1 event on 5 is correctly positionned although its not regular. Surprisingly, when the system has some cpu(?) load, the pen just works fine, and the cursor follow it. for example, To make it work fine, I just need to launch a " while (true) do true; done" on some console screen. It's directly related. also works with heavy X apps, or during app loading time. After some tickling with the code, It appears that the Xorg core function xf86ReadSerial(), used in the core of the module, gives faulty results when the system is quite idle. I've added some debug messages around this function, and the data read from the serial device is correct when the system is under load, but some Bytes are duplicated or NULL are added when the system is at low pace. Therefore, absurd values are read from those bytes and most coordinates are wrong. I didn't spot any repeated pattern or anything regular: or the errors seems inserted at random. The erratic-ness is _proportionnal_ to the load. (Adding too heavy debug messages puts loads on the system, and the bug disappear...) I've tried adjusting serial parameters values line 562, namely Vmin and Vtime, to no avail; but I'm not skilled there and it may still need some tweaking. The command-line program pentest.c, gives perfect results, load or not load. so it is not the pen/screen duo. Tests are done using the same stty/setserial conf even the oldest release of this file on gitweb give the same erratic behavior: the core of the program didn't changed. All of this was done with PROXIMITY at 0x20, so I was wrong, it is not the point. This behavior happened before sometimes, and thinking of it, it was always related to the load. When running, my main application eats a bit of cpu, that is why it does not happen that often in running state. I'm switching to a new one, less hungry, so the bug resurfaced. the tabletPC is a fujitsu 2300 with an _active_ pen. a comment from 2005 speaks about possible broken support for active pen tablets... Any pointers welcomed, especially on _X11_ serial configuration (Vtime, Vmin and all) or a xf86ReadSerial() replacement. jean-marc Bourdaret Créez votre adresse électronique [EMAIL PROTECTED] 1 Go d'espace de stockage, anti-spam et anti-virus intégrés.
