Well, my cuecat driver is ready for testing.
http://zinx.xmms.org/cuecat/cuecat-2.6-0.0.2.tar.gz
It does not use the same output format as the driver floating around
for 2.2.x/2.4.x kernels.
It currently requires a patch which changes the order serio drivers
are searched in (the newest driver is searched first now), and adds
a function to walk through the serio port list.
I'm hoping the patch will be included in to the kernel at some point
in time -- It's available separately at:
http://zinx.xmms.org/cuecat/linux-2.6.0-test9-serio.diff
The driver has some pitfalls, such as standing between -all- serio
devices capable of supporting a cuecat, and not just the ones with
a cuecat on them (And it has no way to specify which ports to use),
but hopefully I'll think of a good way to fix that before 0.0.3.
The major number is dynamicly allocated -- If you aren't using devfs,
check /proc/devices.
The minor number for reading all cuecats is 0, and the minor number
for individual cuecats is their [driver-assigned] index plus 1.
Recommended names are:
/dev/cuecat/cuecats
/dev/cuecat/0
/dev/cuecat/1
and so on.
Questions, comments, patches, and even some flames are welcome.
--
Zinx Verituse
On Wed, Nov 19, 2003 at 07:45:14PM -0600, Zinx Verituse wrote:
> Well, my cuecat driver is ready for testing.
>
> http://zinx.xmms.org/cuecat/cuecat-2.6-0.0.2.tar.gz
>
> It does not use the same output format as the driver floating around
> for 2.2.x/2.4.x kernels.
>
> It currently requires a patch which changes the order serio drivers
> are searched in (the newest driver is searched first now), and adds
> a function to walk through the serio port list.
>
> I'm hoping the patch will be included in to the kernel at some point
> in time -- It's available separately at:
> http://zinx.xmms.org/cuecat/linux-2.6.0-test9-serio.diff
>
> The driver has some pitfalls, such as standing between -all- serio
> devices capable of supporting a cuecat, and not just the ones with
> a cuecat on them (And it has no way to specify which ports to use),
> but hopefully I'll think of a good way to fix that before 0.0.3.
>
> The major number is dynamicly allocated -- If you aren't using devfs,
> check /proc/devices.
> The minor number for reading all cuecats is 0, and the minor number
> for individual cuecats is their [driver-assigned] index plus 1.
> Recommended names are:
> /dev/cuecat/cuecats
> /dev/cuecat/0
> /dev/cuecat/1
> and so on.
Hmm? A 2.6 input driver shouldn't create devices bz itself but rather use
the input core to communicated with the upper drivers like evdev or moused..
On Thu, Nov 20, 2003 at 11:32:49AM +0000, Christoph Hellwig wrote:
> On Wed, Nov 19, 2003 at 07:45:14PM -0600, Zinx Verituse wrote:
[snip]
> >
> > The major number is dynamicly allocated -- If you aren't using devfs,
> > check /proc/devices.
> > The minor number for reading all cuecats is 0, and the minor number
> > for individual cuecats is their [driver-assigned] index plus 1.
> > Recommended names are:
> > /dev/cuecat/cuecats
> > /dev/cuecat/0
> > /dev/cuecat/1
> > and so on.
>
> Hmm? A 2.6 input driver shouldn't create devices bz itself but rather use
> the input core to communicated with the upper drivers like evdev or moused..
>
The input core really is designed for actual input devices, rather
than devices that send out arbitrary largish amounts of data.
The driver would probably be simplified a bit (superficially) by
sending barcodes as events (it would have to be multiple events
per barcode -- the input core has very small communications with
userland), but it would complicate userspace quite a bit, and it's
really just not the sort of thing I'd expect in the input core.
However, if you can think of a way to send the barcodes as a single
event, without changing the userland input core interface, I'm all
ears :)
--
Zinx Verituse