Hi,
I've taken over maintenance of the cpia driver for CPiA-based
webcams (eg. Creative WebCam II, both usb and parport variants).
While I am mainly interested in usb, I am trying to fix up some
outstanding issues with parport support.
I have just implemented the CPiA double-speed variant( see [1] below]
of nibble mode, so one can now get almost the same (slow) image stream capture
on non-ECP, non-TRISTATE ports as with software-emulated ECP on
non-ECP but TRISTATE-capable ports.
Here's the problem:
In both software-emulated ECP (TRISTATE non-ECP ports) and
now this Nibble variant on non-TRISTATE, non-ECP ports, the transfer is
so cpu intensive that the X-windows becomes blocked (no mouse pointer response
while an image transfer takes place). I'm getting about 1 byte in 13 usec
(75K/sec) in the "nibble stream" protocol[1], and the (compressed) image frame
can be 20K - 350K (max is if it changes completely from the previous frame).
Breaking up the transmission across the parport into
chunks of 2048 Bytes helps a lot, by shortening the "dead" period
between mouse pointer responses.
There is a user-mode port of the Windows driver (mcam) that doesnt
cause this blocking of the X-windows response during the image frame
transmissions, so it is possible.
Does anyone has any suggestions for some way I can get my kernel-mode
implementation to behave nicely by not grabbing all available cpu
resources while processing the nibbles as they dribble across
the parport interface, (IF that is what is causing the problem, but maybe
it's some other issue? I have no experience with this, as I am a parport
novice; what else could be causing it --- some lock?).
Is this an issue of kernel-non-premptability ?(I'd like to fix it for 2.4.x
(>2.4.20) kernels, if possible).
Could putting some delays between transmission of data chunks help?
(Hmm, maybe I'll try postpoing unscrambling and reassembling the nibbles
into bytes until the whole chunk of data is available in "nibble stream mode")
Thanks for any thoughts/advice/suggestions.
Duncan
(I also need to get ECP-with-DMA working .... need to get a ECP port card for
that, though, and only have free PCI slots ...Does 2.4.x have working DMA
support for ECP ports?)
--------------------------------------
[1] For image streams on non-"BiDiR" ports, CpiA uses a nonstandard "nibble
stream" protocol that sends the second nibble in response to the host setting
nAutoFd HI after the first nibble, instead of waiting for nAutoFd to go LO
again; for reading camera registers it uses a "standard" nibble protocol, but
doesn't set nDataAvail (nFault LO) after every Byte received, as
parport_ieee1284_read_nibble() (and, I guess, the ieee1284 standard) requires.
I got this working by pointing port->ops->nibble_read_data
to modified private functions derived from parport_ieee1284_read_nibble(),
using the GPL'd Windows driver and the available CPiA spec sheet as a guide;
reverse-engineering this by trial-and-error would have been a nightmare!
----------------------------------
E-Mail: Duncan Haldane <f.duncan.m.haldane@worldnet.att.net>
Date: 27-Dec-2002
Time: 14:12:10
This message was sent by XFMail
----------------------------------
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Fri Dec 27 2002 - 16:56:46 EST