0.8.2:	Again, no change. Just a new patch for Linux 2.4.21.

0.8.1:	No change in the driver. The patch against 2.4.20 is virtually the same
	as the one against 2.4.12.

0.8.0:	Keith Owens and Alan Cox introduced the "tainted" mechanism in the
	kernel and in the modutils to determine if one or more kernel modules
	that are not GPL have been insmoded, or if they have been insmoded by
	force. The kernel now provides the /proc/sys/kernel/tainted file, which
	is really only a placeholder to store an integer, and insmod/modprobe
	use it to store 1 if a module was not GPL (or at least if didn't declare
	itself as being GPL, which is rather different), 2 if a module was
	insmoded by force, and 3 if a non-GPL module was insmoded by force.
	The CueCat driver is GPL, so we should tell insmod. This mechanism
	only work with the latest modutils (v2.4.10 and above).

0.7.1:	Linus called the 2.4.11 kernel a "sorry excuse for a kernel" because of
	a small blooper he left in it. He calls for people not to use it and
	he has released the 2.4.12 kernel instead. So I'm going along and
	releasing a patch for 2.4.12, and deprecating the patch for 2.4.11
	(despite the fact that they are the same) :-)

0.7.0:	I thought DigitalConvergence and RadioShack had given up on the
	"all-USB" CueCat but I was wrong : I was given several today at RS, and
	they work fine with the CueCat driver. They report the same manufacturer
	and product IDs as the "forbidden" one I obtained a year ago, and they
	even bear the same serial number, so it's the real thing.
	
	With newer versions of the 2.4 kernel, two possible USB modules can
	handle keyboard devices (hid.o and usbkbd.o), where previously only
	hid.o could. The new hid.o module however is not the same as the old
	one, and seems to have some problems with USB CueCat devices : older
	USB CueCats will be seen by hid.o, flicker briefly but stay turned off
	afterward. Newer USB CueCats and PS/2 <-> USB CueCat adapters will
	be seen by hid.o, turned on, but will eventually be turned off and the
	CueCat will start blinking slowly. The usbkbd.o module doesn't seem to
	create those problems and seems to behave like the old hid.o module.

0.6.1:	Again, no change to the driver. I only forked off the CueAct archive,
	because it really has no place in the CueCat driver archive. This should
	be the last "silly" version change.

0.6.0:	No change to the driver, but an addition to the CueAct utility : the
	companion utility "DCdb" that has been added is a program that looks up
	barcodes in the online barcode database maintained by
	DigitalConvergence. Many people asked why CueAct didn't do anything
	with the "cues" in the RadioShack catalog, and up to now I have been
	reluctant to use the DigitalConvergence database, because I don't
	want them to accuse me of stealing from their effort, or something
	silly like that, because that's not what I want to do. Instead, I want
	their business model to succeed so they can pay their bills and
	salaries and keep making free CueCats. Therefore, DCdb has the ability
	to pass DigitalConvergence-issued registration codes and CueCat IDs
	along to their database, so they get their marketing data just like with
	their Windows CRQ software, and we Linux people can use their "cues".

0.5.0:	It looks like DigitalConvergence or RadioShack decided to abandon the
	"all-USB" CueCat that never got released and sell a USB adapter instead
	for about US$10 to convert PS/2 CueCats already around. That's really
	quite smart. The little device shows up in the USB stack as a HID
	device with manufacturer ID 0458 and device ID 0102. The
	original USB CueCat showed up with device ID 0101. Apart from the
	incremented device ID number, the PS/2 CueCat/USB adapter combination
	behaves exactly like the original USB CueCat, so apart from a small
	change in the kernel hook to catch the new device ID, the rest is
	unchanged and works just fine.

0.4.0:	The patch against kernel 2.4.7 is only marginally different from the
	patch against 2.4.0-test10, but different enough to justify a new
	release.

0.3.0:	Well well, I finally switched over to 2.4.0 for good. There are some
	bizarre things in the 2.4 kernel, like the C++-ish fops structure. But
	overall, the CueCat driver only underwent minor changes to compile.
	Also, keybdev has moved to drivers/input, and is not in drivers/usb
	anymore. Finally, the driver doesn't make use of "handle_scancode()"
	anymore, but calls "handle_keyboard_event()" instead, which is nice and
	unifies with the use of "handle_mouse_event()".

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 :)
