0.1.9:	Doh ! I updated cuecat_scancodes2ascii.h with Stephen Satchell's ',' and
	'/' characters but I had forgotten to do the same with cuecat_at2xt.h.
	
0.1.8:	Stephen Satchell reports :

	--8<--8<--SNIP-SNIP--8<--8<--
	I encoded "<<<===>>>" with Code 128, and here is what my RS CueCat
	(05a00) reported:

	.C3nZC3nZC3nZCNzYDNPYC3nX.CNf7.F39-FN5,Fx19.

	header=
	devid=000000000151591002
	codetype=128
	barcode=<<<===>>>
	trailer=

	Now, the Forbes cat (07a00) reports what you guys are seeing:

	.C3nZC3nZC3nXDhD3C3rZCxnX.CNf7.F39-FN5+Fx19.

	header=
	devid=000000002744070202
	codetype=128
	barcode=<<<===>>>
	trailer=

	I changed my decoder program to accept EITHER + or , at position 62, and
	- or / at position 63.  Ah, the joy of kludges...
	--8<--8<--SNIP-SNIP--8<--8<--

	So, it sounds like the data output from various versions of the CueCat
	is not very consistent. None of my CueCats return ',' or '/', but it
	doesn't cost anything to add these values.

0.1.7:	I hate this but I had to make two patches for this release, one for
	2.2.16 without the USB backport and one for 2.2.16 with the USB backport
	to use a USB CueCat. I am still against using 2.4 as it is just too
	unstable for me, but as soon as I can use it, the version of the CueCat
	driver for 2.4 will have only one patch again.

0.1.6:	Only additions for this release, no change to the driver or the decoder.

0.1.4:	Peter Anvin gave us an official major and minor, so no more device
	file shuffling. Also, since CueCats return device IDs, we now collect
	data from all the CueCats and make them available on only one device
        file.


0.1.3:	Well, following Brad Jorsh's PS/2 CueCat patch, I have decided to move
	the regular keyboard port hook from keyboard.c (more or less hardware
	independant) to pc_keyb.c (PC/AT architecture dependant. I'm very very
	sorry to say that this will hurt people who have managed to use the
	0.1.2 driver with a PPC or an Alpha machine. Basically, now, the new
	policy if you want to add support for the CueCat on hardware other than
 	PC/AT is to implement a new hook in the relevant hardware driver and add
	specific treatment in the cuecat_driver. Sorry guys, I would like very
	much to make the driver more hardware independant, but the coolness of
	the CueCat-on-PS/2 is just too much. Moreover, I reckon it's a more
	logical approach to have different hooks for different ports.

	Also, I have decided tentatively to adopt Brad's "very very early"
	barcode detection method, at the arrival of an ALT-press, instead of
	of an ALT-press-F10-press, like I did before. I re-thought about his
	argument, and tried it myself, and indeed the ALT is not that jerky
	with his method, even on a 386. I had rejected the change before because
	of some reports that ALT was not very nice to use anymore with this.
	Wait and see ...

	In order to support more than one barcode at a time, I had to rewrite
	the decoder so that it uses a state structure that's passed to it,
	instead of internal global vars. It actually makes much more sense, so
	even if the PS/2 CueCat ends up dropping, that modification will stay.

	Finally, I have changed the major to 60 (instead of 66, which is
	apparently taken) and grabbed minors 0 and 1. I'm still waiting for
	a more enlightened choice :)
