Merge branch 'master' of http://expresskeys.ruivo.org/expresskeys
[expresskeys.git] / ChangeLog
1 _Version 0.4.2 26 Jun 2008_
2
3 * added support for Wacom Cintiq 20WSX
4 * made the g4 tablet structure more maintainable
5 * g4 pad buttons are 9 and 13 not 9 and 10
6
7 _Version 0.4.1 28 Mar 2007_
8
9 * Implemented a slightly better logic for Touch Strip movement detection.
10 This cuts down on "false positives" that can happen when the user lifts a
11 finger and places it on another spot, instead of dragging the finger there.
12
13 But even with this improved logic, false positives still happen if the touched
14 spots are too close to each other (one position up/down), and at the same time
15 have been recorded as being in the same "direction" in relation to the previous
16 movement.
17
18 To make it perfect we would have to examine Proximity Out events as well as
19 finger position. But that is not feasible - from what I've seen - since both
20 buttons and strips generate identical out of proximity events, coming from the
21 same "pad" device.
22
23 * With linuxwacom-0.7.7-3, xsetwacom got a parametre named TabletID (as a
24 synonym for GetTabletID). Since we base our whole tablet identification routine
25 on a correct return from that program, and don't know if the old form will
26 disappear in the future, TabletID henceforth is our first choice - with
27 GetTabletID as a backup.
28
29 This means that users with an older linuxwacom package will see a harmless
30 message from xsetwacom, for each detected device, when running directly in a
31 console: "Get: Unknown parameter 'TabletID'".
32
33 * Bugfix: While looking for a daemon instance of expresskeys, we parse the file
34 /proc/[PID-nr]/status and compare the program name there with the one read from
35 our own status.log. Unfortunately, the /proc file truncates program names to
36 15 chars, so an executable named eg expresskeys-0.4.0 would not be seen as
37 running even when it was.
38
39 We now also examine /proc/[PID-nr]/cmdline to catch such long names.
40
41 * The xerror_handler() in on_error.c used static numbers when checking
42 error_event->error_code Not good... Now changed to a better approach. And
43 having searched the net _extensively_ for solutions to this elusive X
44 programming problem, coming up with precious little, I've decided to quote
45 myself right here. Perhaps some search engine will index it for other hunters:
46
47 [...]
48 #include <X11/Xlib.h> /* XErrorEvent also pulls in X11/X.h with BadWindow def.*/
49 #include <X11/extensions/XIproto.h> /* Minor opcode error: X_OpenDevice */
50 [...]
51 int xerror_handler(Display* display, XErrorEvent* error_event)
52 {
53 /* There seems to be no standard way to catch an "BadDevice, invalid or
54  uninitialized input device" error when trying to open devices which aren't
55  plugged in. The extension error code varies (I've seen 169 and 170 myself)
56  and the message string could be localized as well. Therefore we take a
57  two-pronged approach here: Just return if the error code falls within the
58  extension error range (>= 128) and at the same time is a X_OpenDevice
59  "Minor opcode" as defined in X11/extensions/XIproto.h
60    Also, in rare cases we might hit "BadWindow (invalid Window parameter)"
61  (code 3) when looking for the present focus-window. I've only seen it with
62  the "Firefox Preferences" window, but we better ignore any such case
63  (standard error code from X11/X.h pulled in through X11/Xlib.h): */
64         if (((error_event->error_code >= 128)
65         && (error_event->minor_code == X_OpenDevice))
66         || (error_event->error_code == BadWindow)) {
67                 return 0;
68         }
69 [...]
70 }
71
72
73 _Version 0.4.0 28 Nov 2006_
74
75 OBSERVE: linuxwacom-0.7.5-2 or greater is now required for ALL tablets!
76
77 I would most prominently like to thank Magnus Vigerlof. His initial code
78 review of expresskeys 0.3.0 sparked an interest in refactoring. When Graphire4
79 was tacked on in 0.3.1 it became obvious that the code needed a total rewrite.
80 Since then I've forced myself on Magnus whenever a bit of guidance has been
81 sought. His suggestions, always technically sound and never patronizing, have
82 influenced my decisions to quite a degree. The resulting code however, can not
83 be blamed on anyone but me. The Sorcerer's Apprentice from Fantasia conveys a
84 proper guilt dispersion...
85
86 * A maximum of fifteen tablets (three of each model), and two styli per tablet,
87 are now handled concurrently.
88
89 'Models': nopad, Graphire4 BlueTooth, Graphire4, Intuos3 small, Intuos3/Cintiq
90
91 Corresponding configuration files, for each connected tablet, are differentiated
92 through their suffixes (.conf1 .conf2 .conf3): padless.conf1/2/3,
93 graphire4bt.conf1/2/3, graphire4.conf1/2/3, intuos3s.conf1/2/3 and
94 intuos3.conf1/2/3.
95
96 Observe that the files _not_ are locked to specific tablets. On program start
97 the first found tablet of a certain model gets to use the .conf1 file, etc.
98
99 To aid in configuration/debugging and possibly help external programs to
100 make an educated guess about the current connections, we print out easily
101 parsed lines in the status.log (and to the screen in -v[erbose] mode) Eg:
102
103 /home/loke/.expresskeys/status.log
104
105 [...]
106 OUR CNFFILE = /home/loke/.expresskeys/intuos3.conf1
107 ConfigVersion-user = 4
108 ConfigVersion-ours = 4
109 CurrentPad  = pad1i3
110 CurrentSty1 = stylus1i3
111 CurrentSty2 = LACKING
112
113 [...]
114 OUR CNFFILE = /home/loke/.expresskeys/graphire4.conf1
115 ConfigVersion-user = 4
116 ConfigVersion-ours = 4
117 CurrentPad  = pad1g4
118 CurrentSty1 = stylus1g4
119 CurrentSty2 = LACKING
120
121 * A maximum of 32 keycodes can now be sent with each tablet button press
122 (Touch Strip movement/Scroll Wheel up-down). Because of this, all the "Plus"
123 fields from prior configuration file versions have been eliminated in
124 ConfigVersion 4.
125
126 Since a ConfigVersion 3 only will be correctly parsed on the first read,
127 not on re-reads, we do not support that version at all. Sorry, it became too
128 convoluted a code to retain backwards compatibility.
129
130 * Control of button auto-repeat has been implemented. No longer is X in charge,
131 wildly spewing out keycodes at the merest hint of a lingering button press.
132 Henceforth each and every button can have auto-repeat turned off or on,
133 depending on taste and target window (program). Also, as a sanity measure, the
134 auto-repeat will teminate on a focus-window change:
135
136 RepeatButton9/etc (I3), RepeatLeft/RepeatRight (G4) - Switch 1/0
137
138 Furthermore, we now have configurable delays:
139
140 ButtonRepeatAfter (wait before starting auto-repeat) - 0.01 to 10 seconds
141 DelayButtonRepeat (wait between each repetition) - 0.01 to 10 seconds
142
143 * Touch Strip auto-repeat has been implemented for the top and bottom positions:
144
145 RepeatLeftUp/RepeatLeftDown/etc - Switch 1/0
146 TouchRepeatAfter (wait before starting auto-repeat) - 0.01 to 10 seconds
147 DelayTouchRepeat (wait between each repetition) - 0.01 to 10 seconds
148
149 * To finalize the control aspect, a delay between each keycode sent can be
150 added. While reading a Wacom support forum (Windows/Mac only) I saw a
151 user asking for this feature. A target program of his would choke on the
152 keys coming in, since they came too fast. He had tried delaying by the use of
153 'dummy' keys like Escape and Space, but that could not rectify the problem.
154
155 So here we have a feature not (yet) available in the Win/Mac experience:
156
157 DelayEachKeycode (wait between sending of each keycode) - 0.01 to 10 seconds
158
159 * More fake keycodes. This time to implement tablet rotation from a button.
160 And, as I've gradually have seen a benefit to changing the stylus PressCurve
161 interactively from a button, make the user aware of that option by writing
162 it out in a first-time created configuration file (and in the USAGE file).
163 The implementation has been available ever since version 0.2.2, but the
164 documentation only in that ChangeLog entry - which nobody reads...
165
166 Here is a verbatim quote from the USAGE file:
167
168 + Fake keycodes: 1001, 1002, 1003 +
169 Instead of defining a fixed stylus PressCurve for different program blocks,
170 you can use three values as keycodes to alter the curve interactively. 1001
171 will decrease the PressCurve, while 1003 will increase it. 1002 restores the
172 curve to its default state: "0 0 100 100". Both the upward and downward curve
173 changes flip over in a carousel fashion at the top and bottom values.
174
175 + Fake keycodes: 1004, 1005, 1006, 1007, 1008, 1009 +
176 Use the value 1004 to return from a tablet rotation (NONE), 1005 to flip a
177 tablet 180 degrees (HALF), 1006 to rotate 90 degrees clock-wise (CW) and
178 1007 to rotate 90 degrees counter-clock-wise (CCW). By using 1008 you can
179 rotate the tablet endlessly in a clock-wise manner (CW-HALF-CCW-NONE-CW-)
180 and 1009 does the same motion counter-clock-wise (CCW-HALF-CW-NONE-CCW-).
181 Looking down on the tablet and tilting the head '90' degrees to the right
182 would simulate a CW operation.
183
184 * The code refactoring has of course enhanced the quality in many ways not
185 immediately obvious to the user. For example: We now filter out any illegal
186 keycode already at the configuration read stage; there is a more accurate
187 detection of whether a PID-file is 'live' or not; tablets defined in xorg.conf
188 but not plugged in at program start will not cause a termination with
189 "BadDevice, invalid or uninitialized input device" (though at least ONE
190 tablet must be connected at program start, otherwise we exit).
191
192 If I've forgotten to mention anything new in 0.4.0 you can always read the
193 code. It is very easy nowadays since no line stretches beyond column 80 (with
194 a tab-size of 8), and a lot of other coding conventions are followed as well.
195