
_Version 0.4.1 28 Mar 2007_

* Implemented a slightly better logic for Touch Strip movement detection.
This cuts down on "false positives" that can happen when the user lifts a
finger and places it on another spot, instead of dragging the finger there.

But even with this improved logic, false positives still happen if the touched
spots are too close to each other (one position up/down), and at the same time
have been recorded as being in the same "direction" in relation to the previous
movement.

To make it perfect we would have to examine Proximity Out events as well as
finger position. But that is not feasible - from what I've seen - since both
buttons and strips generate identical out of proximity events, coming from the
same "pad" device.

* With linuxwacom-0.7.7-3, xsetwacom got a parametre named TabletID (as a
synonym for GetTabletID). Since we base our whole tablet identification routine
on a correct return from that program, and don't know if the old form will
disappear in the future, TabletID henceforth is our first choice - with
GetTabletID as a backup.

This means that users with an older linuxwacom package will see a harmless
message from xsetwacom, for each detected device, when running directly in a
console: "Get: Unknown parameter 'TabletID'".

* Bugfix: While looking for a daemon instance of expresskeys, we parse the file
/proc/[PID-nr]/status and compare the program name there with the one read from
our own status.log. Unfortunately, the /proc file truncates program names to
15 chars, so an executable named eg expresskeys-0.4.0 would not be seen as
running even when it was.

We now also examine /proc/[PID-nr]/cmdline to catch such long names.

* The xerror_handler() in on_error.c used static numbers when checking
error_event->error_code Not good... Now changed to a better approach. And
having searched the net _extensively_ for solutions to this elusive X
programming problem, coming up with precious little, I've decided to quote
myself right here. Perhaps some search engine will index it for other hunters:

[...]
#include <X11/Xlib.h> /* XErrorEvent also pulls in X11/X.h with BadWindow def.*/
#include <X11/extensions/XIproto.h> /* Minor opcode error: X_OpenDevice */
[...]
int xerror_handler(Display* display, XErrorEvent* error_event)
{
/* There seems to be no standard way to catch an "BadDevice, invalid or
 uninitialized input device" error when trying to open devices which aren't
 plugged in. The extension error code varies (I've seen 169 and 170 myself)
 and the message string could be localized as well. Therefore we take a
 two-pronged approach here: Just return if the error code falls within the
 extension error range (>= 128) and at the same time is a X_OpenDevice
 "Minor opcode" as defined in X11/extensions/XIproto.h
   Also, in rare cases we might hit "BadWindow (invalid Window parameter)"
 (code 3) when looking for the present focus-window. I've only seen it with
 the "Firefox Preferences" window, but we better ignore any such case
 (standard error code from X11/X.h pulled in through X11/Xlib.h): */
	if (((error_event->error_code >= 128)
	&& (error_event->minor_code == X_OpenDevice))
	|| (error_event->error_code == BadWindow)) {
		return 0;
	}
[...]
}


_Version 0.4.0 28 Nov 2006_

OBSERVE: linuxwacom-0.7.5-2 or greater is now required for ALL tablets!

I would most prominently like to thank Magnus Vigerlof. His initial code
review of expresskeys 0.3.0 sparked an interest in refactoring. When Graphire4
was tacked on in 0.3.1 it became obvious that the code needed a total rewrite.
Since then I've forced myself on Magnus whenever a bit of guidance has been
sought. His suggestions, always technically sound and never patronizing, have
influenced my decisions to quite a degree. The resulting code however, can not
be blamed on anyone but me. The Sorcerer's Apprentice from Fantasia conveys a
proper guilt dispersion...

* A maximum of fifteen tablets (three of each model), and two styli per tablet,
are now handled concurrently.

'Models': nopad, Graphire4 BlueTooth, Graphire4, Intuos3 small, Intuos3/Cintiq

Corresponding configuration files, for each connected tablet, are differentiated
through their suffixes (.conf1 .conf2 .conf3): padless.conf1/2/3,
graphire4bt.conf1/2/3, graphire4.conf1/2/3, intuos3s.conf1/2/3 and
intuos3.conf1/2/3.

Observe that the files _not_ are locked to specific tablets. On program start
the first found tablet of a certain model gets to use the .conf1 file, etc.

To aid in configuration/debugging and possibly help external programs to
make an educated guess about the current connections, we print out easily
parsed lines in the status.log (and to the screen in -v[erbose] mode) Eg:

/home/loke/.expresskeys/status.log

[...]
OUR CNFFILE = /home/loke/.expresskeys/intuos3.conf1
ConfigVersion-user = 4
ConfigVersion-ours = 4
CurrentPad  = pad1i3
CurrentSty1 = stylus1i3
CurrentSty2 = LACKING

[...]
OUR CNFFILE = /home/loke/.expresskeys/graphire4.conf1
ConfigVersion-user = 4
ConfigVersion-ours = 4
CurrentPad  = pad1g4
CurrentSty1 = stylus1g4
CurrentSty2 = LACKING

* A maximum of 32 keycodes can now be sent with each tablet button press
(Touch Strip movement/Scroll Wheel up-down). Because of this, all the "Plus"
fields from prior configuration file versions have been eliminated in
ConfigVersion 4.

Since a ConfigVersion 3 only will be correctly parsed on the first read,
not on re-reads, we do not support that version at all. Sorry, it became too
convoluted a code to retain backwards compatibility.

* Control of button auto-repeat has been implemented. No longer is X in charge,
wildly spewing out keycodes at the merest hint of a lingering button press.
Henceforth each and every button can have auto-repeat turned off or on,
depending on taste and target window (program). Also, as a sanity measure, the
auto-repeat will teminate on a focus-window change:

RepeatButton9/etc (I3), RepeatLeft/RepeatRight (G4) - Switch 1/0

Furthermore, we now have configurable delays:

ButtonRepeatAfter (wait before starting auto-repeat) - 0.01 to 10 seconds
DelayButtonRepeat (wait between each repetition) - 0.01 to 10 seconds

* Touch Strip auto-repeat has been implemented for the top and bottom positions:

RepeatLeftUp/RepeatLeftDown/etc - Switch 1/0
TouchRepeatAfter (wait before starting auto-repeat) - 0.01 to 10 seconds
DelayTouchRepeat (wait between each repetition) - 0.01 to 10 seconds

* To finalize the control aspect, a delay between each keycode sent can be
added. While reading a Wacom support forum (Windows/Mac only) I saw a
user asking for this feature. A target program of his would choke on the
keys coming in, since they came too fast. He had tried delaying by the use of
'dummy' keys like Escape and Space, but that could not rectify the problem.

So here we have a feature not (yet) available in the Win/Mac experience:

DelayEachKeycode (wait between sending of each keycode) - 0.01 to 10 seconds

* More fake keycodes. This time to implement tablet rotation from a button.
And, as I've gradually have seen a benefit to changing the stylus PressCurve
interactively from a button, make the user aware of that option by writing
it out in a first-time created configuration file (and in the USAGE file).
The implementation has been available ever since version 0.2.2, but the
documentation only in that ChangeLog entry - which nobody reads...

Here is a verbatim quote from the USAGE file:

+ Fake keycodes: 1001, 1002, 1003 +
Instead of defining a fixed stylus PressCurve for different program blocks,
you can use three values as keycodes to alter the curve interactively. 1001
will decrease the PressCurve, while 1003 will increase it. 1002 restores the
curve to its default state: "0 0 100 100". Both the upward and downward curve
changes flip over in a carousel fashion at the top and bottom values.

+ Fake keycodes: 1004, 1005, 1006, 1007, 1008, 1009 +
Use the value 1004 to return from a tablet rotation (NONE), 1005 to flip a
tablet 180 degrees (HALF), 1006 to rotate 90 degrees clock-wise (CW) and
1007 to rotate 90 degrees counter-clock-wise (CCW). By using 1008 you can
rotate the tablet endlessly in a clock-wise manner (CW-HALF-CCW-NONE-CW-)
and 1009 does the same motion counter-clock-wise (CCW-HALF-CW-NONE-CCW-).
Looking down on the tablet and tilting the head '90' degrees to the right
would simulate a CW operation.

* The code refactoring has of course enhanced the quality in many ways not
immediately obvious to the user. For example: We now filter out any illegal
keycode already at the configuration read stage; there is a more accurate
detection of whether a PID-file is 'live' or not; tablets defined in xorg.conf
but not plugged in at program start will not cause a termination with
"BadDevice, invalid or uninitialized input device" (though at least ONE
tablet must be connected at program start, otherwise we exit).

If I've forgotten to mention anything new in 0.4.0 you can always read the
code. It is very easy nowadays since no line stretches beyond column 80 (with
a tab-size of 8), and a lot of other coding conventions are followed as well.

